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

[ffmpegagent]

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,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

softworkz (2):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows

 libavformat/os_support.h   |  16 ++--
 libavutil/file_open.c  |   2 +-
 libavutil/wchar_filename.h | 166 +
 3 files changed, 178 insertions(+), 6 deletions(-)


base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa
Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-28%2Fsoftworkz%2Fsubmit_long_filenames-v5
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-28/softworkz/submit_long_filenames-v5
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/28

Range-diff vs v4:

 1:  13118dc1fa = 1:  13118dc1fa avutil/wchar_filename,file_open: Support long 
file names on Windows
 2:  252ed89499 ! 2:  5313aeec0e avformat/os_support: Support long file names 
on Windows
 @@ libavformat/os_support.h
  +
  +struct win32_stat
  +{
 -+_dev_t st_dev;
 -+_ino_t st_ino;
 -+unsigned short st_mode;
 -+short  st_nlink;
 -+short  st_uid;
 -+short  st_gid;
 -+_dev_t st_rdev;
 -+__int64st_size;
 -+__time64_t st_atime;
 -+__time64_t st_mtime;
 -+__time64_t st_ctime;
 ++struct _stati64;
  +};
  +
   #  ifdef fstat

-- 
ffmpeg-codebot
___
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 v5 1/2] avutil/wchar_filename, file_open: Support long file names on Windows

[softworkz]

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 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -45,7 +45,7 @@ static int win32_open(const char *filename_utf8, int oflag, 
int pmode)
 wchar_t *filename_w;
 
 /* convert UTF-8 to wide chars */
-if (utf8towchar(filename_utf8, &filename_w))
+if (get_extended_win32_path(filename_utf8, &filename_w))
 return -1;
 if (!filename_w)
 goto fallback;
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f082452c..94f8ce54b5 100644
--- a/libavutil/wchar_filename.h
+++ b/libavutil/wchar_filename.h
@@ -40,6 +40,172 @@ static inline int utf8towchar(const char *filename_utf8, 
wchar_t **filename_w)
 MultiByteToWideChar(CP_UTF8, 0, filename_utf8, -1, *filename_w, num_chars);
 return 0;
 }
+
+/**
+ * Checks for extended path prefixes for which normalization needs to be 
skipped.
+ * see .NET6: PathInternal.IsExtended()
+ */
+static inline int path_is_extended(const wchar_t *path)
+{
+if (path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?') && path[2] 
== L'?' && path[3] == L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Checks for a device path prefix.
+ * see .NET6: PathInternal.IsDevicePath()
+ */
+static inline int path_is_device_path(const wchar_t *path)
+{
+if (path[0] == L'\\' && path[1] == L'\\' && path[2] == L'.' && path[3] == 
L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Performs path normalization by calling GetFullPathNameW().
+ * see .NET6: PathHelper.GetFullPathName()
+ */
+static inline int get_full_path_name(wchar_t **ppath_w)
+{
+int num_chars;
+wchar_t *temp_w;
+
+num_chars = GetFullPathNameW(*ppath_w, 0, NULL, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+temp_w = (wchar_t *)av_calloc(num_chars, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+
+num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+/**
+ * Normalizes a Windows file or folder path.
+ * Expansion of short paths (with 8.3 path components) is currently omitted
+ * as it is not required for accessing long paths.
+ * see .NET6: PathHelper.Normalize().
+ */
+static inline int path_normalize(wchar_t **ppath_w)
+{
+int ret;
+
+if ((ret = get_full_path_name(ppath_w)) < 0)
+return ret;
+
+/* What .NET does at this point is to call 
PathHelper.TryExpandShortFileName()
+ * in case the path contains a '~' character.
+ * We don't need to do this as we don't need to normalize the file name
+ * for presentation, and the extended path prefix works with 8.3 path
+ * components as well
+ */
+return 0;
+}
+
+/**
+ * Adds an extended path or UNC prefix to longs paths or paths ending
+ * with a space or a dot. (' ' or '.').
+ * This function expects that the path has been normalized before by
+ * calling path_normalize() and it doesn't check whether the path is
+ * actually long (> MAX_PATH).
+ * see .NET6: PathInternal.EnsureExtendedPrefix() *
+ */
+static inline int add_extended_prefix(wchar_t **ppath_w)
+{
+const wchar_t *unc_prefix   = L"?\\UNC\\";
+const wchar_t *extended_path_prefix = L"?\\";
+const wchar_t *path_w   = *ppath_w;
+const size_t len= wcslen(path_w);
+wchar_t *temp_w;
+
+/* We're skipping the check IsPartiallyQualified() because
+ * we expect to have called GetFullPathNameW() already. */
+if (len < 2 || path_is_extended(*ppath_w) || 
path_is_device_path(*ppath_w)) {
+return 0;
+}
+
+if (path_w[0] == L'\\' && path_w[1] == L'\\') {
+/* unc_prefix length is 8 plus 1 for terminating zeros,
+ * we subtract 2 for the leading '\\' of the original path */
+temp_w = (wchar_t *)av_calloc(len - 2 + 8 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(temp_w, unc_prefix);
+wcscat(temp_w, path_w + 2);
+} else {
+// The length of extended_path_prefix is 4 plus 1 for terminating zeros
+temp_w = (wchar_t *)av_calloc(len + 4 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(temp_w, extended_path_prefix);
+wcscat(temp_w, path_w);
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+/**
+ * Converts a file or folder path to wchar_t for use with Windows file
+ * APIs. Paths with extended path prefix (either '\\?\' or 

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

[softworkz]

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_support.h
@@ -49,7 +49,13 @@
 #  ifdef stat
 #   undef stat
 #  endif
-#  define stat _stati64
+#  define stat win32_stat
+
+struct win32_stat
+{
+struct _stati64;
+};
+
 #  ifdef fstat
 #   undef fstat
 #  endif
@@ -153,7 +159,7 @@ static inline int win32_##name(const char *filename_utf8) \
 wchar_t *filename_w;  \
 int ret;  \
   \
-if (utf8towchar(filename_utf8, &filename_w))  \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
 return -1;\
 if (!filename_w)  \
 goto fallback;\
@@ -177,7 +183,7 @@ static inline int win32_##name(const char *filename_utf8, 
partype par) \
 wchar_t *filename_w;  \
 int ret;  \
   \
-if (utf8towchar(filename_utf8, &filename_w))  \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
 return -1;\
 if (!filename_w)  \
 goto fallback;\
@@ -199,9 +205,9 @@ static inline int win32_rename(const char *src_utf8, const 
char *dest_utf8)
 wchar_t *src_w, *dest_w;
 int ret;
 
-if (utf8towchar(src_utf8, &src_w))
+if (get_extended_win32_path(src_utf8, &src_w))
 return -1;
-if (utf8towchar(dest_utf8, &dest_w)) {
+if (get_extended_win32_path(dest_utf8, &dest_w)) {
 av_free(src_w);
 return -1;
 }
-- 
ffmpeg-codebot
___
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 v5] avcodec/mfenc: Dynamically load MFPlat.DLL

[Martin Storsjö]

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, avcodec will be linked directly against MFPlat.DLL.
 - MediaFoundation functions are now called like MFTEnumEx, like Martin
   Storsjö suggested in his review of the v3.

I forgot to mention it on earlier versions, this patch addresses
https://trac.ffmpeg.org/ticket/9788.


diff --git a/libavcodec/mf_utils.c b/libavcodec/mf_utils.c
index eeabd0ce0b..b8756cccea 100644
--- a/libavcodec/mf_utils.c
+++ b/libavcodec/mf_utils.c
@@ -24,6 +24,7 @@

 #include "mf_utils.h"
 #include "libavutil/pixdesc.h"
+#include "compat/w32dlfcn.h"

 HRESULT ff_MFGetAttributeSize(IMFAttributes *pattr, REFGUID guid,
   UINT32 *pw, UINT32 *ph)
@@ -47,9 +48,83 @@ HRESULT ff_MFSetAttributeSize(IMFAttributes *pattr, REFGUID 
guid,
 #define ff_MFSetAttributeRatio ff_MFSetAttributeSize
 #define ff_MFGetAttributeRatio ff_MFGetAttributeSize

-// MFTEnumEx was missing from mingw-w64's mfplat import library until
-// mingw-w64 v6.0.0, thus wrap it and load it using GetProcAddress.
-// It's also missing in Windows Vista's mfplat.dll.
+// Windows N editions does not provide MediaFoundation by default.
+// So to avoid DLL loading error, MediaFoundation is dynamically loaded except
+// on UWP build since LoadLibrary is not available on it.
+#if !HAVE_UWP
+static HMODULE mf_library = NULL;
+
+int ff_mf_load_library(void *log)
+{
+mf_library = win32_dlopen("mfplat.dll");
+
+if (!mf_library) {
+av_log(log, AV_LOG_ERROR, "DLL mfplat.dll failed to open\n");
+return AVERROR_UNKNOWN;
+}
+
+return 0;
+}
+
+void ff_mf_unload_library(void)
+{
+FreeLibrary(mf_library);
+mf_library = NULL;
+}

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 when you probably could just call LoadLibrary 
directly. (There's no need for using wchar APIs and long path handling and 
all that, when it's just given the hardcoded path "mfplat.dll".)


Secondly, this won't probably work as intended if you have two mfenc 
instances running at the same time - you'd load the library twice but only 
unload it once. To work around that, you can either add some sort of 
reference counting around the library, or keep the library reference in a 
per-encoder struct.


In this case I think I would prefer to keep it in a struct.

+
+#define GET_MF_FUNCTION(ptr, func_name) \
+ptr = (void *)GetProcAddress(mf_library, #func_name ""); \

Why the extra "" here?

+if (!ptr) \
+return E_FAIL;
+#else
+// In UWP (which lacks LoadLibrary), just link directly against
+// the functions - this requires building with new/complete enough
+// import libraries.
+#define GET_MF_FUNCTION(ptr, func_name) \
+ptr = func_name; \
+if (!ptr) \
+return E_FAIL;
+#endif
+
+HRESULT ff_MFStartup(ULONG Version, DWORD dwFlags)
+{
+HRESULT (WINAPI *MFStartup_ptr)(ULONG Version, DWORD dwFlags) = NULL;
+GET_MF_FUNCTION(MFStartup_ptr, MFStartup);

For functions like this, fetching the function pointer every time it's 
called probably is fine (as it's only called once on startup), but ...


+return MFStartup_ptr(Version, dwFlags);
+}
+
+HRESULT ff_MFShutdown(void)
+{
+HRESULT (WINAPI *MFShutdown_ptr)(void) = NULL;
+GET_MF_FUNCTION(MFShutdown_ptr, MFShutdown);
+return MFShutdown_ptr();
+}
+
+HRESULT ff_MFCreateSample(IMFSample **ppIMFSample)
+{
+HRESULT (WINAPI *MFCreateSample_ptr)(IMFSample **ppIMFSample) = NULL;
+GET_MF_FUNCTION(MFCreateSample_ptr, MFCreateSample);

This is called once per frame at least, right? For such cases I think it 
would be much better if we'd keep the function pointer in a struct (which 
then would be owned/contained in MFContext) so we don't need to look it up 
every time.


@@ -1034,7 +1034,11 @@ static int mf_create(void *log, IMFTransform **mft, 
const AVCodec *codec, int us
 return 0;
 }

+#if !HAVE_UWP
+static int mf_init_encoder(AVCodecContext *avctx)
+#else
 static int mf_init(AVCodecContext *avctx)
+#endif
 {
 MFContext *c = avctx->priv_data;
 HRESULT hr;
@@ -1134,6 +1138,10 @@ static int mf_close(AVCodecContext *avctx)

 ff_free_mf(&c->mft);

+#if !HAVE_UWP
+ff_mf_unload_library();
+#endif
+
 av_frame_free(&c->frame);

 av_freep(&avctx->extradata);
@@ -1142,6 +1150,21 @@ static int mf_close(AVCodecContext *avctx)
 return 0;
 }

+#if !HAVE_UWP
+static int mf_init(AVCodecContext *avctx)
+{
+int ret;
+
+if ((ret = ff_mf_load_library(avctx)) == 0) {
+   if ((ret = mf_init_encoder(avctx)) == 0) {
+return 0;
+}

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

[Xiang, Haihao]

> > -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 released 3 years ago, it is easy to get a greater
> > version than 1.28. We may remove lots of compile-time checks if adding
> > the requirement for the minimal version in the configure script.
> > ---

[...]
> > LookAheadDepth: %"PRIu16"\n",
> > -   info->ICQQuality, co2->LookAheadDepth);
> > -}
> > -#endif
> > -#if QSV_HAVE_QVBR
> > -else if (info->RateControlMethod == MFX_RATECONTROL_QVBR) {
> > -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
> > -   co3->QVBRQuality);
> > +av_log(avctx, AV_LOG_VERBOSE, "ICQQuality: %"PRIu16"\n", info-
> > > ICQQuality);
> 
> This branch is now identical with the previous one. But I wouldn't 
> mind leaving it like this as it's better readable.
> 
> Probably somebody will mind the curly brace formatting around else if,
> though.
> 

Thanks for pointing it out. I'll change it when merging the patch.

[...]
> 
> LGTM. This patch is a great improvement to the qsv code as it is dropping
> a lot of old and unnecessary clutter.
> 

Thanks for reviewing this patch. I'll applying it if no more comment. 

BRs
Haihao



___
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] libavcodec/qsvenc: expose only supported options

[Xiang, Haihao]

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 and
> mpeg2 significantly fall behind. This creates difficulties
> for the users to use qsv encoders. This patch fixes options
> list for encoders leaving only those which are actually
> supported.
> 
> Signed-off-by: Dmitry Rogozhkin 
> ---
>  libavcodec/qsvenc.h   | 52 ++--
> ---
>  libavcodec/qsvenc_h264.c  | 12 +++
>  libavcodec/qsvenc_hevc.c  |  9 
>  libavcodec/qsvenc_mpeg2.c |  1 +
>  4 files changed, 60 insertions(+), 14 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index cb84723..33bbc2a 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -89,22 +89,46 @@
>  { "slow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_TARGETUSAGE_3  },INT_MIN, INT_MAX, VE, "preset"
> },\
>  { "slower",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_TARGETUSAGE_2  },INT_MIN, INT_MAX, VE, "preset"
> },\
>  { "veryslow",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_TARGETUSAGE_BEST_QUALITY  }, INT_MIN, INT_MAX, VE, "preset"
> },\
> -{ "rdo","Enable rate distortion
> optimization",OFFSET(qsv.rdo),AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,  1, VE }, \
> +{ "forced_idr", "Forcing I frames as IDR
> frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 =
> 0  },  0,  1, VE }, \
> +{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> -1}, -1, 1, VE},
> +
> +#define QSV_OPTION_RDO \
> +{ "rdo","Enable rate distortion
> optimization",OFFSET(qsv.rdo),AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,  1, VE },
> +
> +#define QSV_OPTION_MAX_FRAME_SIZE \
>  { "max_frame_size", "Maximum encoded frame size in
> bytes",OFFSET(qsv.max_frame_size), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,INT_MAX, VE }, \
>  { "max_frame_size_i", "Maximum encoded I frame size in
> bytes",OFFSET(qsv.max_frame_size_i), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,  INT_MAX, VE }, \
> -{ "max_frame_size_p", "Maximum encoded P frame size in
> bytes",OFFSET(qsv.max_frame_size_p), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,  INT_MAX, VE }, \
> -{ "max_slice_size", "Maximum encoded slice size in
> bytes",OFFSET(qsv.max_slice_size), AV_OPT_TYPE_INT, { .i64 = -1 },
> -1,INT_MAX, VE }, \
> -{ "bitrate_limit",  "Toggle bitrate
> limitations", OFFSET(qsv.bitrate_limit),  AV_OPT_TYPE_INT, { .i64
> = -1 }, -1,  1, VE }, \
> -{ "mbbrc",  "MB level bitrate
> control",   OFFSET(qsv.mbbrc),  AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
> -{ "extbrc", "Extended bitrate
> control",   OFFSET(qsv.extbrc), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
> -{ "adaptive_i", "Adaptive I-frame
> placement", OFFSET(qsv.adaptive_i), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
> -{ "adaptive_b", "Adaptive B-frame
> placement", OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
> -{ "p_strategy", "Enable P-pyramid: 0-default 1-simple 2-pyramid(bf need
> to be set to 0).",OFFSET(qsv.p_strategy), AV_OPT_TYPE_INT,{ .i64 = 0},
> 0,2, VE }, \
> -{ "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE
> }, \
> -{ "forced_idr", "Forcing I frames as IDR
> frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 =
> 0  },  0,  1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> -1}, -1, 1, VE},\
> -{ "dblk_idc", "This option disable deblocking. It has value in range
> 0~2.",   OFFSET(qsv.dblk_idc),   AV_OPT_TYPE_INT,{ .i64 = 0
> },   0,  2,  VE},\
> -{ "low_delay_brc",   "Allow to strictly obey avg frame size",
> OFFSET(qsv.low_delay_brc),  AV_OPT_TYPE_BOOL,{ .i64 = -1 }, -1,  1, VE
> }, \
> +{ "max_frame_size_p", "Maximum encoded P frame size in
> bytes"

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

[Martin Storsjö]

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 Windows
v6: Add avfilter/file_open.c to "Files without standard license headers"
list
v7: Rebase and use the new avpriv_fopen_utf8() instead

softworkz (2):
 avfilter: use av_fopen_utf8() instead of plain fopen()
 avcodec/dvdsubdec: use av_fopen_utf8() instead of plain fopen()


Pushed, with the commit messages updated to use avpriv_fopen_utf8 too.

// Martin

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

[Martin Storsjö]

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_open.c
index fb64c2e4ee..58a6073353 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -45,7 +45,7 @@ static int win32_open(const char *filename_utf8, int oflag, 
int pmode)
wchar_t *filename_w;

/* convert UTF-8 to wide chars */
-if (utf8towchar(filename_utf8, &filename_w))
+if (get_extended_win32_path(filename_utf8, &filename_w))
return -1;


Note, the caller expects that if the function returned an error, all 
temporary allocations made by the function have been freed - the caller 
doesn't need to free those allocations.



if (!filename_w)
goto fallback;
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f082452c..94f8ce54b5 100644
--- a/libavutil/wchar_filename.h
+++ b/libavutil/wchar_filename.h
@@ -40,6 +40,172 @@ static inline int utf8towchar(const char *filename_utf8, 
wchar_t **filename_w)
MultiByteToWideChar(CP_UTF8, 0, filename_utf8, -1, *filename_w, num_chars);
return 0;
}
+
+/**
+ * Checks for extended path prefixes for which normalization needs to be 
skipped.
+ * see .NET6: PathInternal.IsExtended()
+ */
+static inline int path_is_extended(const wchar_t *path)
+{
+if (path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?') && path[2] == L'?' 
&& path[3] == L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Checks for a device path prefix.
+ * see .NET6: PathInternal.IsDevicePath()
+ */
+static inline int path_is_device_path(const wchar_t *path)
+{
+if (path[0] == L'\\' && path[1] == L'\\' && path[2] == L'.' && path[3] == 
L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Performs path normalization by calling GetFullPathNameW().
+ * see .NET6: PathHelper.GetFullPathName()
+ */
+static inline int get_full_path_name(wchar_t **ppath_w)
+{
+int num_chars;
+wchar_t *temp_w;
+
+num_chars = GetFullPathNameW(*ppath_w, 0, NULL, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+temp_w = (wchar_t *)av_calloc(num_chars, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+
+num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;


In this error handling path, you leak the allocated temp_w


+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+/**
+ * Normalizes a Windows file or folder path.
+ * Expansion of short paths (with 8.3 path components) is currently omitted
+ * as it is not required for accessing long paths.
+ * see .NET6: PathHelper.Normalize().
+ */
+static inline int path_normalize(wchar_t **ppath_w)
+{
+int ret;
+
+if ((ret = get_full_path_name(ppath_w)) < 0)
+return ret;
+
+/* What .NET does at this point is to call 
PathHelper.TryExpandShortFileName()
+ * in case the path contains a '~' character.
+ * We don't need to do this as we don't need to normalize the file name
+ * for presentation, and the extended path prefix works with 8.3 path
+ * components as well
+ */
+return 0;
+}
+
+/**
+ * Adds an extended path or UNC prefix to longs paths or paths ending
+ * with a space or a dot. (' ' or '.').
+ * This function expects that the path has been normalized before by
+ * calling path_normalize() and it doesn't check whether the path is
+ * actually long (> MAX_PATH).
+ * see .NET6: PathInternal.EnsureExtendedPrefix() *
+ */
+static inline int add_extended_prefix(wchar_t **ppath_w)
+{
+const wchar_t *unc_prefix   = L"?\\UNC\\";
+const wchar_t *extended_path_prefix = L"?\\";
+const wchar_t *path_w   = *ppath_w;
+const size_t len= wcslen(path_w);
+wchar_t *temp_w;
+
+/* We're skipping the check IsPartiallyQualified() because
+ * we expect to have called GetFullPathNameW() already. */
+if (len < 2 || path_is_extended(*ppath_w) || 
path_is_device_path(*ppath_w)) {
+return 0;
+}
+
+if (path_w[0] == L'\\' && path_w[1] == L'\\') {
+/* unc_prefix length is 8 plus 1 for terminating zeros,
+ * we subtract 2 for the leading '\\' of the original path */
+temp_w = (wchar_t *)av_calloc(len - 2 + 8 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(temp_w, unc_prefix);
+wcscat(temp_w, path_w + 2);
+} else {
+// The length of extended_path_prefix is 4 plus 1 for terminating zeros
+temp_w = (wchar_t *)av_calloc(len + 4 + 1, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+wcscpy(

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

[Thilo Borgmann]

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
___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Martin Storsjö]

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/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -49,7 +49,13 @@
#  ifdef stat
#   undef stat
#  endif
-#  define stat _stati64
+#  define stat win32_stat
+
+struct win32_stat
+{
+struct _stati64;
+};


Is it possible to work around this issue by doing "#define stat(a,b)" 
which only should apply on the function, not to the struct? Then we can't 
redirect "struct stat" into "struct _stati64" at the same time...


A safe way forward could be to switch code to just using "struct 
ff_stat_struct", and define ff_stat_struct to the name of the struct we 
exepct to use. It's not pretty, and it affects users which no longer can 
use the default POSIX stat form of the calls, but it would fix the issue 
of redirecting the struct and function separately, without needing to know 
what exactly is in the struct (because we really shouldn't be 
hardcoding/assuming that).


// Martin

___
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/3] fftools: Stop using av_fopen_utf8

[Martin Storsjö]

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 do that later at some point, but I don't see it as 
urgent.



- I have kept the path functions in the same way like .NET does it,
 just for easy reference and following. Compilers will inline
 them anyway (my pov). Maybe others don't like that. I can change
 if it's got to be.


Having the individual functions inline compared to merging it all in one 
big function doesn't matter to me. But the amount of code in this inline 
header is growing a bit big, to the point that I think it is measurable 
when multiple files within the same library use these functions. Longer 
term, it would probably make sense to make them more shared in some way.


If C would have the C++ style deduplication feature for non-static inline 
functions, this wouldn't be an issue. One could consider making them ff_ 
functions and carry a copy in each library too, maybe. (But that also 
makes it trickier to use in fftools.) Not entirely urgent yet anyway.


// Martin

___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Soft Works]

> -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 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/libavformat/os_support.h
> > +++ b/libavformat/os_support.h
> > @@ -49,7 +49,13 @@
> > #  ifdef stat
> > #   undef stat
> > #  endif
> > -#  define stat _stati64
> > +#  define stat win32_stat
> > +
> > +struct win32_stat
> > +{
> > +struct _stati64;
> > +};
> 
> Is it possible to work around this issue by doing "#define stat(a,b)"
> which only should apply on the function, not to the struct? 

How could this be possible? A define is only doing string replacements,
so I wouldn't know how it could be restricted to the function, but 
not the struct.

> A safe way forward could be to switch code to just using "struct
> ff_stat_struct", and define ff_stat_struct to the name of the struct we
> exepct to use. It's not pretty, and it affects users which no longer can
> use the default POSIX stat form of the calls

That's why I took the effort to make this work.

> but it would fix the issue
> of redirecting the struct and function separately, without needing to know
> what exactly is in the struct (because we really shouldn't be
> hardcoding/assuming that).

That doesn't apply because the current code already does this:

DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)

Which means that it specifically chooses _stati64 which is a public
MS API: 

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170

And we know that it takes _stati64 as the parameter.

This code:

struct win32_stat
{
struct _stati64;
};

makes use of a MS compiler feature called "anonymous structures":

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/z2cx9y4f(v=vs.120)?redirectedfrom=MSDN

This way, we automatically "inherit" the members of the struct
(whatever their members would be).


Thanks for reviewing,
softworkz

___
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

[Soft Works]

> -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
> 
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of nil-
> > admir...@mailo.com
> > Sent: Monday, May 23, 2022 5:36 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/2] avutil/wchar_filename,
> > file_open: Support long file names on Windows
> >
> > >> Not possible for stat precisely because of function and struct
> sharing
> > a
> > >> name.
> >
> > > That's exactly what is said above and before :-)
> >
> > My previous question was not answered, so I had to look up the answer
> > myself.
> >
> > > I'm actually wondering how does it even compile. All stat structs in
> > code
> > > become struct win32_stat, and all calls to stat become calls to
> > win32_stat,
> > > which in turn wraps _wstati64. But _wstati64 does not accept struct
> > win32_stat*,
> > > it accepts struct _stati64*. Content of these structs is probably
> > identical, but
> > > it should not matter: C is typed nominally, not structurally.
> >
> > Turns out C actually has a concept of compatible types:
> > https://en.cppreference.com/w/c/language/type.
> >
> > The problems is:
> > > they are both structure/union/enumeration types, and
> > > - (c99) if one is declared with a tag, the other must also be declared
> > with the same tag.
> > > ...
> > > If two declarations refer to the same object or function and do not
> use
> > compatible types,
> > > the behavior of the program is undefined.
> >
> > Your structure does not have the same tag as the CRT's one.
> > Are you sure you want to rely on undefined behaviour?
> >
> > I haven't compiled your code, but the following simple example:
> >
> > struct A { int a, b, c; };
> > struct B { int a, b, c; };
> > void printA(struct A *a);
> >
> > struct B b = { 1, 2, 3 };
> > printA(&b);
> >
> > generates a
> >
> > warning: passing argument 1 of ‘printA’ from incompatible pointer type
> [-
> > Wincompatible-pointer-types]
> > | printA(&b);
> > |^~
> > ||
> > |struct B *
> > note: expected ‘struct A *’ but argument is of type ‘struct B *’
> > | void printA(struct A *a)
> >
> > Are you sure you wanna add a couple of similar warnings to the project?
> 
> This is not what's happening. No warnings, not even from clang diagnostics
> with -Weverything.

I'm sorry, you were right and I was wrong. The includes and macros had hidden
away all the warnings.

For my new solution which I had submitted today, I had made a test in a code
file where I put all the new things directly and expanded the macros.

This gives in fact the kind of error you mentioned:

... function': incompatible types - from 'win32_stat *' to '_stat64 *'


I had explained the way it works to Martin in another response. The 
relevant part is:

The struct:

struct win32_stat
{
struct _stati64;
};

makes use of a MS compiler feature called "anonymous structures":
This way, we automatically "inherit" the members of the struct.

Now, that still gives the incompatible type warning. 

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 win32_stat function like this:


static inline int win32_stat(const char *filename_utf8, struct win32_stat *par)
{
wchar_t *filename_w;
int ret;
if (get_extended_win32_path(filename_utf8, &filename_w))
return -1;
if (!filename_w)
goto fallback;
ret = _wstat64(filename_w, &par->stat);
av_free(filename_w);
return ret;
fallback:
  return _stat64(filename_utf8, &par->stat);
}

so it uses the ->stat member for doing the api calls while
the calling (ffmpeg) code can use the structure as if it was the 
actual POSIX stat structure.


Kind regards,
sw





___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Martin Storsjö]

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 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/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -49,7 +49,13 @@
#  ifdef stat
#   undef stat
#  endif
-#  define stat _stati64
+#  define stat win32_stat
+
+struct win32_stat
+{
+struct _stati64;
+};


Is it possible to work around this issue by doing "#define stat(a,b)"
which only should apply on the function, not to the struct?


How could this be possible? A define is only doing string replacements,
so I wouldn't know how it could be restricted to the function, but
not the struct.


If unsure about a tool feature, please try it out for yourself. Yes, a 
define is only a string replacement, but a define with parameters only 
matches the string occurs with parenthesis afterwards. Consider this 
example:


$ cat test.c
#define stat(a, b) win32_stat(a, b)

struct stat {
int a, b, c;
};

void stat (struct stat *st, const char* filename);

void func(const char* filename) {
struct stat st;
stat (&st, filename);
}
$ cc -E test.c
# 1 "test.c"
# 1 ""
# 1 ""
# 31 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 32 "" 2
# 1 "test.c"


struct stat {
 int a, b, c;
};

void win32_stat(struct stat *st, const char* filename);

void func(const char* filename) {
 struct stat st;
 win32_stat(&st, filename);
}


So here, the stat -> win32_stat rewrite only applied on the function 
declaration and call, but not on the structs.


Not saying that this necessarily is the way forward, but I was just 
mentioning it as a potential option to consider.



A safe way forward could be to switch code to just using "struct
ff_stat_struct", and define ff_stat_struct to the name of the struct we
exepct to use. It's not pretty, and it affects users which no longer can
use the default POSIX stat form of the calls


That's why I took the effort to make this work.


but it would fix the issue
of redirecting the struct and function separately, without needing to know
what exactly is in the struct (because we really shouldn't be
hardcoding/assuming that).


That doesn't apply because the current code already does this:

DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)

Which means that it specifically chooses _stati64 which is a public
MS API:

https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170

And we know that it takes _stati64 as the parameter.


Yes, there is no disagreement about that part.


This code:

   struct win32_stat
   {
   struct _stati64;
   };

makes use of a MS compiler feature called "anonymous structures":

https://docs.microsoft.com/en-us/previous-versions/visualstudio/visual-studio-2013/z2cx9y4f(v=vs.120)?redirectedfrom=MSDN

This way, we automatically "inherit" the members of the struct
(whatever their members would be).


This, as the article itself clearly declares, is a C language extension. 
GCC allows it in mingw mode, but Clang doesn't. (It's possible to use it 
in Clang too if you enable it with -fms-extensions though.)


$ cat test2.c
struct orig_struct {
int a, b, c;
};
struct my_struct {
struct orig_struct;
};
void set(struct my_struct *st) {
st->a = 42;
}
$ clang -target x86_64-w64-mingw32 -c test2.c
test2.c:5:2: warning: declaration does not declare anything 
[-Wmissing-declarations]
struct orig_struct;
^
test2.c:8:6: error: no member named 'a' in 'struct my_struct'
st->a = 42;
~~  ^
1 warning and 1 error generated.
$ clang -target x86_64-w64-mingw32 -c test2.c -fms-extensions
test2.c:5:2: warning: anonymous structs are a Microsoft extension 
[-Wmicrosoft-anon-tag]
struct orig_struct;
^
1 warning generated.


// Martin
___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Soft Works]

> -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, 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  de...@ffmpeg.org>
> >> Cc: softworkz ; Hendrik Leppkes
> >> 
> >> Subject: 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/libavformat/os_support.h
> >>> +++ b/libavformat/os_support.h
> >>> @@ -49,7 +49,13 @@
> >>> #  ifdef stat
> >>> #   undef stat
> >>> #  endif
> >>> -#  define stat _stati64
> >>> +#  define stat win32_stat
> >>> +
> >>> +struct win32_stat
> >>> +{
> >>> +struct _stati64;
> >>> +};
> >>
> >> Is it possible to work around this issue by doing "#define stat(a,b)"
> >> which only should apply on the function, not to the struct?
> >
> > How could this be possible? A define is only doing string replacements,
> > so I wouldn't know how it could be restricted to the function, but
> > not the struct.
> 
> If unsure about a tool feature, please try it out for yourself.

I did :-)
(very extensively in fact)

> Yes, a
> define is only a string replacement, but a define with parameters only
> matches the string occurs with parenthesis afterwards. 

Yes, that's true, but we need to rename both, the function and the
struct, not just the function.


Your example doesn't quite match the situation.

// Let's start with the pre-requisites which cannot be changed
// Posix definitions (stat.h)
struct stat {
int a, b, c;
};

// This is the regular definition
int stat(char *fileName, struct stat *par)

// With your define, we replace the function, but not the 
// struct. So we would call the WinAPI function with 
// the wrong struct.
#define stat(a, b) win32_stat(a, b)

// I don't know why you have this in your example at
// this place. It comes from some include file and
// it is not the one we need to use.
// if you mean to redefine it here: that was my previous
// approach. You need to copy the struct (but rename it)
struct stat {
int a, b, c;
};

// - other example:

// This function needs to call the windows function,
// so we cannot use the regular stat struct as parameter
void win32_stat(struct stat *st, const char* filename);



> So here, the stat -> win32_stat rewrite only applied on the function
> declaration and call, but not on the structs.

Exactly, but the struct must be rewritten as well and this is not
possible. 

Neither this:

#define stat _stati64
#define stat(a, b) win32_stat(a, b)

nor this:

#define stat(a, b) win32_stat(a, b)
#define stat _stati64

is working (yes, I tried ;-)

> This, as the article itself clearly declares, is a C language extension.
> GCC allows it in mingw mode

Yes I had read about that.

> but Clang doesn't. (It's possible to use it
> in Clang too if you enable it with -fms-extensions though.)

Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to 
compile Windows stuff).


Thanks again,
sw
___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Martin Storsjö]

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 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 
de...@ffmpeg.org>

Cc: softworkz ; Hendrik Leppkes

Subject: 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/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -49,7 +49,13 @@
#  ifdef stat
#   undef stat
#  endif
-#  define stat _stati64
+#  define stat win32_stat
+
+struct win32_stat
+{
+struct _stati64;
+};


Is it possible to work around this issue by doing "#define stat(a,b)"
which only should apply on the function, not to the struct?


How could this be possible? A define is only doing string replacements,
so I wouldn't know how it could be restricted to the function, but
not the struct.


If unsure about a tool feature, please try it out for yourself.


I did :-)
(very extensively in fact)


Yes, a
define is only a string replacement, but a define with parameters only
matches the string occurs with parenthesis afterwards.


Yes, that's true, but we need to rename both, the function and the
struct, not just the function.



I know. But you said:

How could this be possible? A define is only doing string replacements, 
so I wouldn't know how it could be restricted to the function, but not 
the struct.


And I showed how a define can apply to only one but not the other. Which 
seemed to be news to in your prior mail.


Note how I also said:

"Not saying that this necessarily is the way forward, but I was just 
mentioning it as a potential option to consider."



Your example doesn't quite match the situation.


Yes I know.

I just brought it up as a possibly thing for discussion, and you derailed 
it by discussing whether it even works. Yes it works, but after looking 
more into it, I agree that it probably won't help in this situation.



but Clang doesn't. (It's possible to use it
in Clang too if you enable it with -fms-extensions though.)


Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to
compile Windows stuff).


Yes, it is possible to build it with Clang without any custom extra flags 
to enable nondefault modes. In fact, it's tested continuously on FATE too:


http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk

Also for other architectures, e.g.:

http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk

// Martin
___
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] lavc/aarch64: add hevc horizontal qpel/uni/bi

[J. Dekker]

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_h12_8_neon: 438.5
put_hevc_qpel_bi_h16_8_c: 2663.2
put_hevc_qpel_bi_h16_8_neon: 561.5
put_hevc_qpel_bi_h24_8_c: 6039.0
put_hevc_qpel_bi_h24_8_neon: 1717.5
put_hevc_qpel_bi_h32_8_c: 11104.2
put_hevc_qpel_bi_h32_8_neon: .0
put_hevc_qpel_bi_h48_8_c: 25175.2
put_hevc_qpel_bi_h48_8_neon: 4983.7
put_hevc_qpel_bi_h64_8_c: 42806.5
put_hevc_qpel_bi_h64_8_neon: 8848.5
put_hevc_qpel_h4_8_c: 149.7
put_hevc_qpel_h4_8_neon: 68.2
put_hevc_qpel_h6_8_c: 318.5
put_hevc_qpel_h6_8_neon: 105.2
put_hevc_qpel_h8_8_c: 577.0
put_hevc_qpel_h8_8_neon: 133.2
put_hevc_qpel_h12_8_c: 1276.0
put_hevc_qpel_h12_8_neon: 394.5
put_hevc_qpel_h16_8_c: 2278.2
put_hevc_qpel_h16_8_neon: 517.5
put_hevc_qpel_h24_8_c: 5081.7
put_hevc_qpel_h24_8_neon: 1546.5
put_hevc_qpel_h32_8_c: 9081.0
put_hevc_qpel_h32_8_neon: 2054.0
put_hevc_qpel_h48_8_c: 20280.7
put_hevc_qpel_h48_8_neon: 4615.5
put_hevc_qpel_h64_8_c: 36042.0
put_hevc_qpel_h64_8_neon: 8197.5
put_hevc_qpel_uni_h4_8_c: 165.5
put_hevc_qpel_uni_h4_8_neon: 73.5
put_hevc_qpel_uni_h6_8_c: 366.5
put_hevc_qpel_uni_h6_8_neon: 118.5
put_hevc_qpel_uni_h8_8_c: 661.7
put_hevc_qpel_uni_h8_8_neon: 138.2
put_hevc_qpel_uni_h12_8_c: 1440.5
put_hevc_qpel_uni_h12_8_neon: 399.5
put_hevc_qpel_uni_h16_8_c: 2489.0
put_hevc_qpel_uni_h16_8_neon: 532.2
put_hevc_qpel_uni_h24_8_c: 5896.5
put_hevc_qpel_uni_h24_8_neon: 1558.5
put_hevc_qpel_uni_h32_8_c: 10675.5
put_hevc_qpel_uni_h32_8_neon: 2092.2
put_hevc_qpel_uni_h48_8_c: 24103.0
put_hevc_qpel_uni_h48_8_neon: 4680.2
put_hevc_qpel_uni_h64_8_c: 42789.2
put_hevc_qpel_uni_h64_8_neon: 8330.0

Signed-off-by: J. Dekker 
---
 libavcodec/aarch64/Makefile   |   1 +
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  43 +-
 libavcodec/aarch64/hevcdsp_qpel_neon.S| 520 ++
 3 files changed, 563 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/aarch64/hevcdsp_qpel_neon.S

diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index c8935f205e..2f95649c66 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -65,4 +65,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) += 
aarch64/vp9itxfm_16bpp_neon.o   \
aarch64/vp9mc_neon.o
 NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o 
\
aarch64/hevcdsp_init_aarch64.o  
\
+   aarch64/hevcdsp_qpel_neon.o 
\
aarch64/hevcdsp_sao_neon.o
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c 
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 1e40be740c..ca2cb7cf97 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -58,7 +58,21 @@ void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, 
uint8_t *_src,
   int16_t *sao_offset_val, int sao_left_class,
   int width, int height);
 
-
+void ff_hevc_put_hevc_qpel_h4_8_neon(int16_t *dst, uint8_t *_src, ptrdiff_t 
_srcstride, int height, intptr_t mx, intptr_t my, int width);
+void ff_hevc_put_hevc_qpel_h6_8_neon(int16_t *dst, uint8_t *_src, ptrdiff_t 
_srcstride, int height, intptr_t mx, intptr_t my, int width);
+void ff_hevc_put_hevc_qpel_h8_8_neon(int16_t *dst, uint8_t *_src, ptrdiff_t 
_srcstride, int height, intptr_t mx, intptr_t my, int width);
+void ff_hevc_put_hevc_qpel_h12_8_neon(int16_t *dst, uint8_t *_src, ptrdiff_t 
_srcstride, int height, intptr_t mx, intptr_t my, int width);
+void ff_hevc_put_hevc_qpel_h16_8_neon(int16_t *dst, uint8_t *_src, ptrdiff_t 
_srcstride, int height, intptr_t mx, intptr_t my, int width);
+void ff_hevc_put_hevc_qpel_uni_h4_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int height, intptr_t mx, intptr_t my, int 
width);
+void ff_hevc_put_hevc_qpel_uni_h6_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int height, intptr_t mx, intptr_t my, int 
width);
+void ff_hevc_put_hevc_qpel_uni_h8_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int height, intptr_t mx, intptr_t my, int 
width);
+void ff_hevc_put_hevc_qpel_uni_h12_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int height, intptr_t mx, intptr_t my, int 
width);
+void ff_hevc_put_hevc_qpel_uni_h16_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int height, intptr_t mx, intptr_t my, int 
width);
+void ff_hevc_put_hevc_qpel_bi_h4_8_neon(uint8_t *_dst, ptrdiff_t _dststride, 
uint8_t *_src, ptrdiff_t _srcstride, int16_t *src2, int height, intptr_t mx, 
intptr_t my, 

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

[Anton Khirnov]

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.org with subject "unsubscribe".

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

[Anton Khirnov]

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

[Anton Khirnov]

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

[nil-admirari]

> 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 win32_stat function like this:
>
> static inline int win32_stat(const char *filename_utf8, struct win32_stat 
> *par)
> {
> wchar_t *filename_w;
> int ret;
> if (get_extended_win32_path(filename_utf8, &filename_w))
> return -1;
> if (!filename_w)
> goto fallback;
> ret = _wstat64(filename_w, &par->stat);
> av_free(filename_w);
> return ret;
> fallback:
> return _stat64(filename_utf8, &par->stat);
> }
>
> so it uses the ->stat member for doing the api calls while
> the calling (ffmpeg) code can use the structure as if it was the 
> actual POSIX stat structure.

I'm fine with anonymous union and a rewrite of win32_stat.
But, anonymous unions are a C11 feature: 
https://en.cppreference.com/w/c/language/union,
and C11 is apparently not allowed 
https://ffmpeg.org/developer.html#C-language-features.



___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Soft Works]

> -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 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  de...@ffmpeg.org>;
> >> Hendrik Leppkes 
> >> Subject: 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  >> de...@ffmpeg.org>
>  Cc: softworkz ; Hendrik Leppkes
>  
>  Subject: 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/libavformat/os_support.h
> > +++ b/libavformat/os_support.h
> > @@ -49,7 +49,13 @@
> > #  ifdef stat
> > #   undef stat
> > #  endif
> > -#  define stat _stati64
> > +#  define stat win32_stat
> > +
> > +struct win32_stat
> > +{
> > +struct _stati64;
> > +};
> 
>  Is it possible to work around this issue by doing "#define stat(a,b)"
>  which only should apply on the function, not to the struct?
> >>>
> >>> How could this be possible? A define is only doing string
> replacements,
> >>> so I wouldn't know how it could be restricted to the function, but
> >>> not the struct.
> >>
> >> If unsure about a tool feature, please try it out for yourself.
> >
> > I did :-)
> > (very extensively in fact)
> >
> >> Yes, a
> >> define is only a string replacement, but a define with parameters only
> >> matches the string occurs with parenthesis afterwards.
> >
> > Yes, that's true, but we need to rename both, the function and the
> > struct, not just the function.
> 
> 
> I know. But you said:
> 
> > How could this be possible? A define is only doing string replacements,
> > so I wouldn't know how it could be restricted to the function, but not
> > the struct.
> 
> And I showed how a define can apply to only one but not the other. Which
> seemed to be news to in your prior mail.

Alright yea - thanks for pointing this out. I knew about this kind of
macros, but I hadn't taken them into account in this context because
all my attempts were focusing on the struct side and getting this
separated with typedef and #undef and those things, so it was indeed
opening up a dimension I hadn't considered.
Thanks for the example!


> Note how I also said:
> 
> "Not saying that this necessarily is the way forward, but I was just
> mentioning it as a potential option to consider."
> 
> > Your example doesn't quite match the situation.
> 
> Yes I know.

Sorry, I had understood your message in a way that you would be saying
that it would be working and just not a nice solution.


> I just brought it up as a possibly thing for discussion, and you derailed
> it by discussing whether it even works. 

Nah - I meant whether it works for the given situation, I had no doubt
that your example is working as-is.

 
> >> but Clang doesn't. (It's possible to use it
> >> in Clang too if you enable it with -fms-extensions though.)
> >
> > Is it possible to compile ffmpeg for Windows using Clang?
> > And if yes, does it even work without that flag?
> > (assuming it was introduced in order to be able to
> > compile Windows stuff).
> 
> Yes, it is possible to build it with Clang without any custom extra flags
> to enable nondefault modes. In fact, it's tested continuously on FATE too:
> 
> http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk
> 
> Also for other architectures, e.g.:
> 
> http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk


OK, thanks for the pointers. I'm not sure whether it would be 
acceptable to require this compilation flag for Windows builds?

Can you think of any other ideas?

Thank you very much,
softworkz
___
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 v5 2/2] avformat/os_support: Support long file names on Windows

[Martin Storsjö]

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 Windows

On Tue, 24 May 2022, Soft Works wrote:


but Clang doesn't. (It's possible to use it
in Clang too if you enable it with -fms-extensions though.)


Is it possible to compile ffmpeg for Windows using Clang?
And if yes, does it even work without that flag?
(assuming it was introduced in order to be able to
compile Windows stuff).


Yes, it is possible to build it with Clang without any custom extra flags
to enable nondefault modes. In fact, it's tested continuously on FATE too:

http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk

Also for other architectures, e.g.:

http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk



OK, thanks for the pointers. I'm not sure whether it would be
acceptable to require this compilation flag for Windows builds?


I would very much prefer not to require adding -fms-extensions when 
building with Clang - that option unlocks a lot of stuff that we generally 
shouldn't be enabling.



Can you think of any other ideas?


Right now, mainly doing a #define ff_stat_struct which would require 
updating the calling code. It's not ideal but worse things have been done 
anyway (there's not that many stat calls).


I was exploring the idea of just redefining the struct, but e.g. "typedef 
struct _stati64 win32_stat", but that only works when referring to the 
type as "win32_stat", not "struct win32_stat". So that doesn't seem like a 
good path forward either.


I'd prefer to slow down and think more about other alternatives here, 
rather than rushing forward with adding -fms-extensions.



Also note that currently, we don't even have a proper automatic redirect 
from stat to win32_stat, see the ifdef in libavformat/file.c. So this is 
new development, or, raising the bar even further, in one sense.



// Martin
___
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: add bink2 video decoder

[Paul B Mahol]

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 +++
 libavcodec/codec_desc.c |7 +
 libavcodec/codec_id.h   |1 +
 libavformat/bink.c  |7 +-
 9 files changed, 3206 insertions(+), 4 deletions(-)
 create mode 100644 libavcodec/bink2.c
 create mode 100644 libavcodec/bink2f.c
 create mode 100644 libavcodec/bink2g.c

diff --git a/configure b/configure
index f115b21064..516c3a5db4 100755
--- a/configure
+++ b/configure
@@ -2782,6 +2782,7 @@ atrac3pal_decoder_select="mdct sinewin"
 atrac9_decoder_select="mdct"
 av1_decoder_select="cbs_av1"
 bink_decoder_select="blockdsp hpeldsp"
+bink2_decoder_select="blockdsp"
 binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
 binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs"
 cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 38425d2f22..e6eb8c0854 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -252,6 +252,7 @@ OBJS-$(CONFIG_AYUV_ENCODER)+= v408enc.o
 OBJS-$(CONFIG_BETHSOFTVID_DECODER) += bethsoftvideo.o
 OBJS-$(CONFIG_BFI_DECODER) += bfi.o
 OBJS-$(CONFIG_BINK_DECODER)+= bink.o binkdsp.o
+OBJS-$(CONFIG_BINK2_DECODER)   += bink2.o
 OBJS-$(CONFIG_BINKAUDIO_DCT_DECODER)   += binkaudio.o
 OBJS-$(CONFIG_BINKAUDIO_RDFT_DECODER)  += binkaudio.o
 OBJS-$(CONFIG_BINTEXT_DECODER) += bintext.o cga_data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index c47133aa18..3ae41827a2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -66,6 +66,7 @@ extern const FFCodec ff_ayuv_decoder;
 extern const FFCodec ff_bethsoftvid_decoder;
 extern const FFCodec ff_bfi_decoder;
 extern const FFCodec ff_bink_decoder;
+extern const FFCodec ff_bink2_decoder;
 extern const FFCodec ff_bitpacked_decoder;
 extern const FFCodec ff_bitpacked_encoder;
 extern const FFCodec ff_bmp_encoder;
diff --git a/libavcodec/bink2.c b/libavcodec/bink2.c
new file mode 100644
index 00..102d844c89
--- /dev/null
+++ b/libavcodec/bink2.c
@@ -0,0 +1,479 @@
+/*
+ * Bink video 2 decoder
+ * Copyright (c) 2014 Konstantin Shishkov
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/attributes.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/internal.h"
+#include "avcodec.h"
+#include "blockdsp.h"
+#include "codec_internal.h"
+#include "copy_block.h"
+#include "idctdsp.h"
+#include "internal.h"
+#include "mathops.h"
+
+#define BITSTREAM_READER_LE
+#include "get_bits.h"
+#include "unary.h"
+
+#define BINK_FLAG_ALPHA 0x0010
+#define DC_MPRED(A, B, C) FFMIN(FFMAX((C) + (B) - (A), FFMIN3(A, B, C)), 
FFMAX3(A, B, C))
+#define DC_MPRED2(A, B) FFMIN(FFMAX((A), (B)), FFMAX(FFMIN((A), (B)), 2 * (A) 
- (B)))
+
+static VLC bink2f_quant_vlc;
+static VLC bink2f_ac_val0_vlc;
+static VLC bink2f_ac_val1_vlc;
+static VLC bink2f_ac_skip0_vlc;
+static VLC bink2f_ac_skip1_vlc;
+static VLC bink2g_ac_skip0_vlc;
+static VLC bink2g_ac_skip1_vlc;
+static VLC bink2g_mv_vlc;
+
+static const uint8_t kb2h_num_slices[] = {
+2, 3, 4, 8,
+};
+
+static const uint8_t luma_repos[] = {
+0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15,
+};
+
+static const uint8_t dq_patterns[8] = { 8, 0, 1, 0, 2, 0, 1, 0 };
+
+static const uint8_t bink2_next_skips[] = {
+0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0,
+};
+
+typedef struct QuantPredict {
+int8_t intra_q;
+int8_t inter_q;
+} QuantPredict;
+
+typedef struct DCPredict {
+float dc[4][16];
+int   block_type;
+} DCPredict;
+
+typedef struct DCIPredict {
+int dc[4][16];
+int block_type;
+} DCIPredict;
+
+typedef struct MVectors {
+int v[4][2];
+int nb_vectors;
+} MVectors;
+
+typedef struct MVPredict {
+MVectors mv;
+} MVPredict;
+
+/*
+ * Decoder context
+ */
+typedef struct Bink2Context {
+AVCodecContext  *avctx;
+GetBitContext   gb;
+BlockDSPContext dsp;
+

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

[Soft Works]

> -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 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  de...@ffmpeg.org>;
> >> Hendrik Leppkes 
> >> Subject: RE: [FFmpeg-devel] [PATCH v5 2/2] avformat/os_support: Support
> >> long file names on Windows
> >>
> >> On Tue, 24 May 2022, Soft Works wrote:
> >>
>  but Clang doesn't. (It's possible to use it
>  in Clang too if you enable it with -fms-extensions though.)
> >>>
> >>> Is it possible to compile ffmpeg for Windows using Clang?
> >>> And if yes, does it even work without that flag?
> >>> (assuming it was introduced in order to be able to
> >>> compile Windows stuff).
> >>
> >> Yes, it is possible to build it with Clang without any custom extra
> flags
> >> to enable nondefault modes. In fact, it's tested continuously on FATE
> too:
> >>
> >> http://fate.ffmpeg.org/history.cgi?slot=x86_64-mingw32-clang-trunk
> >>
> >> Also for other architectures, e.g.:
> >>
> >> http://fate.ffmpeg.org/history.cgi?slot=aarch64-mingw32-clang-trunk
> >
> >
> > OK, thanks for the pointers. I'm not sure whether it would be
> > acceptable to require this compilation flag for Windows builds?
> 
> I would very much prefer not to require adding -fms-extensions when
> building with Clang - that option unlocks a lot of stuff that we generally
> shouldn't be enabling.

OK, sure, it always smells when doing something like that just to
achieve a single thing.

> 
> > Can you think of any other ideas?
> 
> Right now, mainly doing a #define ff_stat_struct which would require
> updating the calling code. It's not ideal but worse things have been done
> anyway (there's not that many stat calls).
> 
> I was exploring the idea of just redefining the struct, but e.g. "typedef
> struct _stati64 win32_stat", but that only works when referring to the
> type as "win32_stat", not "struct win32_stat". So that doesn't seem like a
> good path forward either.
> 
> I'd prefer to slow down and think more about other alternatives here,
> rather than rushing forward with adding -fms-extensions.

I have a new idea, see below

> Also note that currently, we don't even have a proper automatic redirect
> from stat to win32_stat, see the ifdef in libavformat/file.c. 

Yes, that can be dropped (once we got it)...


What do you think of the following:

We could define our own win32_stat struct, but not in a way that matches
the Windows API, just matching the POSIX definition (like the consuming 
code expects), e.g.:

struct win_32stat {
dev_t  st_dev; /* ID of device containing file */
ino_t  st_ino; /* inode number */
unsigned short st_mode;/* protection */
short  st_nlink;   /* number of hard links */
short  st_uid; /* user ID of owner */
short  st_gid; /* group ID of owner */
dev_t  st_rdev;/* device ID (if special file) */
off_t  st_size;/* total size, in bytes */
time_t st_atime;   /* time of last access */
time_t st_mtime;   /* time of last modification */
time_t st_ctime;   /* time of last status change */
};

And then, in our win32_stat() function, we call the win api with
the "right" struct and simply copy over the values..:

static int win32_stat(const char *filename_utf8, struct stat *par)
{
wchar_t *filename_w;
int ret;
struct _stati64 winstat;

if (get_extended_win32_path(filename_utf8, &filename_w))
return -1;

if (filename_w) {
ret = _wstat64(filename_w, &winstat);
av_free(filename_w);
} else
ret = _stat64(filename_utf8, &winstat);

par->st_dev   = winstat.st_dev;
par->st_ino   = winstat.st_ino;
par->st_mode  = winstat.st_mode;
par->st_nlink = winstat.st_nlink;
par->st_uid   = winstat.st_uid;
par->st_gid   = winstat.st_gid;
par->st_rdev  = winstat.st_rdev;
par->st_size  = winstat.st_size;
par->st_atime = winstat.st_atime;
par->st_mtime = winstat.st_mtime;
par->st_ctime = winstat.st_ctime;

return ret;
}

This would be safe and without any weirdness (just a bit more
code).

What do you think about it?


Thanks,
sw




___
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 v4 0/1] [WIP] avutil/csp changes

[Michael Niedermayer]

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
> - add 0.5 to the AVR macro definition to get exact values from truncation
> 
> This patch is a work in progress example for swapping these
> structs from doubles to AVRationals.
> 
> There's two main discussions here to be had
> - Is this API to be exposed as avpriv_ or av_?
> - Should these structs use AVRational or double values?
> 
> I don't believe a consensus has been reached on this yet, but I've attached
> an AVRational version of it so we can see the pros/cons.

iam fine with the API (as well as a wide range of variations of this)

thx

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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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 v6 0/2] Support long file names on Windows

[ffmpegagent]

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,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

v6

 * wchar_filename.h: added links to .NET source code
 * wchar_filename.h: free allocations on error
 * os_support.hs: use clean and safe way to redirect stat() calls

softworkz (2):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows

 libavformat/os_support.h   |  87 +-
 libavutil/file_open.c  |   2 +-
 libavutil/wchar_filename.h | 180 +
 3 files changed, 244 insertions(+), 25 deletions(-)


base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa
Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-28%2Fsoftworkz%2Fsubmit_long_filenames-v6
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-28/softworkz/submit_long_filenames-v6
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/28

Range-diff vs v5:

 1:  13118dc1fa ! 1:  960aa795ff avutil/wchar_filename,file_open: Support long 
file names on Windows
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  +/**
  + * Checks for extended path prefixes for which normalization needs to be 
skipped.
  + * see .NET6: PathInternal.IsExtended()
 ++ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L165
  + */
  +static inline int path_is_extended(const wchar_t *path)
  +{
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  +
  +/**
  + * Checks for a device path prefix.
 -+ * see .NET6: PathInternal.IsDevicePath()
 ++ * see .NET6: PathInternal.IsDevice()
 ++ * we don't check forward slashes and extended paths (as already done)
 ++ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L132
  + */
  +static inline int path_is_device_path(const wchar_t *path)
  +{
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  +/**
  + * Performs path normalization by calling GetFullPathNameW().
  + * see .NET6: PathHelper.GetFullPathName()
 ++ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L70
  + */
  +static inline int get_full_path_name(wchar_t **ppath_w)
  +{
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  +
  +num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
  +if (num_chars <= 0) {
 ++av_free(temp_w);
  +errno = EINVAL;
  +return -1;
  +}
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  + * Normalizes a Windows file or folder path.
  + * Expansion of short paths (with 8.3 path components) is currently 
omitted
  + * as it is not required for accessing long paths.
 -+ * see .NET6: PathHelper.Normalize().
 ++ * see .NET6: PathHelper.Normalize()
 ++ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L25
  + */
  +static inline int path_normalize(wchar_t **ppath_w)
  +{
 @@ libavutil/wchar_filename.h: static inline int utf8towchar(const char 
*filename_u
  + * This function expects that the path has been normalized before by
  + * calling path_normalize() and it doesn't check wh

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

[softworkz]

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 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -45,7 +45,7 @@ static int win32_open(const char *filename_utf8, int oflag, 
int pmode)
 wchar_t *filename_w;
 
 /* convert UTF-8 to wide chars */
-if (utf8towchar(filename_utf8, &filename_w))
+if (get_extended_win32_path(filename_utf8, &filename_w))
 return -1;
 if (!filename_w)
 goto fallback;
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f082452c..f36d9dfea3 100644
--- a/libavutil/wchar_filename.h
+++ b/libavutil/wchar_filename.h
@@ -40,6 +40,186 @@ static inline int utf8towchar(const char *filename_utf8, 
wchar_t **filename_w)
 MultiByteToWideChar(CP_UTF8, 0, filename_utf8, -1, *filename_w, num_chars);
 return 0;
 }
+
+/**
+ * Checks for extended path prefixes for which normalization needs to be 
skipped.
+ * see .NET6: PathInternal.IsExtended()
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L165
+ */
+static inline int path_is_extended(const wchar_t *path)
+{
+if (path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?') && path[2] 
== L'?' && path[3] == L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Checks for a device path prefix.
+ * see .NET6: PathInternal.IsDevice()
+ * we don't check forward slashes and extended paths (as already done)
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L132
+ */
+static inline int path_is_device_path(const wchar_t *path)
+{
+if (path[0] == L'\\' && path[1] == L'\\' && path[2] == L'.' && path[3] == 
L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Performs path normalization by calling GetFullPathNameW().
+ * see .NET6: PathHelper.GetFullPathName()
+ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L70
+ */
+static inline int get_full_path_name(wchar_t **ppath_w)
+{
+int num_chars;
+wchar_t *temp_w;
+
+num_chars = GetFullPathNameW(*ppath_w, 0, NULL, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+temp_w = (wchar_t *)av_calloc(num_chars, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+
+num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
+if (num_chars <= 0) {
+av_free(temp_w);
+errno = EINVAL;
+return -1;
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+/**
+ * Normalizes a Windows file or folder path.
+ * Expansion of short paths (with 8.3 path components) is currently omitted
+ * as it is not required for accessing long paths.
+ * see .NET6: PathHelper.Normalize()
+ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L25
+ */
+static inline int path_normalize(wchar_t **ppath_w)
+{
+int ret;
+
+if ((ret = get_full_path_name(ppath_w)) < 0)
+return ret;
+
+/* What .NET does at this point is to call 
PathHelper.TryExpandShortFileName()
+ * in case the path contains a '~' character.
+ * We don't need to do this as we don't need to normalize the file name
+ * for presentation, and the extended path prefix works with 8.3 path
+ * components as well
+ */
+return 0;
+}
+
+/**
+ * Adds an extended path or UNC prefix to longs paths or paths ending
+ * with a space or a dot. (' ' or '.').
+ * This function expects that the path has been normalized before by
+ * calling path_normalize() and it doesn't check whether the path is
+ * actually long (> MAX_PATH).
+ * see .NET6: PathInternal.EnsureExtendedPrefix()
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L107
+ */
+static inline int add_extended_prefix(wchar_t **ppath_w)
+{
+const wchar_t *unc_prefix   = L"?\\UNC\\";
+const wchar_t *extended_path_prefix = L"?\\";
+const wchar_t *path_w   = *ppath_w;
+const size_t len= wcslen(path_w);
+wchar_t *temp_w;
+
+/* We're skipping the check IsPartiallyQualified() because
+ * we expect to have called GetFullPathNameW() already. */
+if (len < 2 || path_is_extended(*ppath_w) || 
path_is_device_path(*ppath_w)) {
+return 0;
+}
+
+if (path_w[0] == L'\\' && path_w[1] == L'\\') {
+/* unc_prefix length is 8 plus 1 for terminating z

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

[softworkz]

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_support.h
+++ b/libavformat/os_support.h
@@ -49,7 +49,24 @@
 #  ifdef stat
 #   undef stat
 #  endif
-#  define stat _stati64
+
+#  define stat win32_stat
+
+struct win32_stat
+{
+_dev_t st_dev; /* ID of device containing file */
+_ino_t st_ino; /* inode number */
+unsigned short st_mode;/* protection */
+short  st_nlink;   /* number of hard links */
+short  st_uid; /* user ID of owner */
+short  st_gid; /* group ID of owner */
+_dev_t st_rdev;/* device ID (if special file) */
+long   st_size;/* total size, in bytes */
+time_t st_atime;   /* time of last access */
+time_t st_mtime;   /* time of last modification */
+time_t st_ctime;   /* time of last status change */
+};
+
 #  ifdef fstat
 #   undef fstat
 #  endif
@@ -153,7 +170,7 @@ static inline int win32_##name(const char *filename_utf8) \
 wchar_t *filename_w;  \
 int ret;  \
   \
-if (utf8towchar(filename_utf8, &filename_w))  \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
 return -1;\
 if (!filename_w)  \
 goto fallback;\
@@ -171,37 +188,59 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
 DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
 DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)
 
-#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
-static inline int win32_##name(const char *filename_utf8, partype par) \
-{ \
-wchar_t *filename_w;  \
-int ret;  \
-  \
-if (utf8towchar(filename_utf8, &filename_w))  \
-return -1;\
-if (!filename_w)  \
-goto fallback;\
-  \
-ret = wfunc(filename_w, par); \
-av_free(filename_w);  \
-return ret;   \
-  \
-fallback: \
-/* filename may be be in CP_ACP */\
-return afunc(filename_utf8, par); \
+static inline int win32_access(const char *filename_utf8, int par)
+{
+wchar_t *filename_w;
+int ret;
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+if (!filename_w)
+goto fallback;
+ret = _waccess(filename_w, par);
+av_free(filename_w);
+return ret;
+fallback:
+return _access(filename_utf8, par);
 }
 
-DEF_FS_FUNCTION2(access, _waccess, _access, int)
-DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
+static inline int win32_stat(const char *filename_utf8, struct stat *par)
+{
+wchar_t *filename_w;
+int ret;
+struct _stati64 winstat = { 0 };
+
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+
+if (filename_w) {
+ret = _wstat64(filename_w, &winstat);
+av_free(filename_w);
+} else
+ret = _stat64(filename_utf8, &winstat);
+
+par->st_dev   = winstat.st_dev;
+par->st_ino   = winstat.st_ino;
+par->st_mode  = winstat.st_mode;
+par->st_nlink = winstat.st_nlink;
+par->st_uid   = winstat.st_uid;
+par->st_gid   = winstat.st_gid;
+par->st_rdev  = winstat.st_rdev;
+par->st_size  = winstat.st_size;
+par->st_atime = winstat.st_atime;
+par->st_mtime = winstat.st_mtime;
+par->st_ctime = winstat.st_ctime;
+
+return ret;
+}
 
 static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
 {
 wchar_t *src_w, *dest_w;
 int ret;
 
-if (utf8towchar(src_utf8, &src_w))
+if (get_extended_win32_path(src_utf8, &src_w))
 return -1;
-if (utf8towchar(dest_utf8, &dest_w)) {
+if (get_extended_win32_path(dest_utf8, &dest_w)) {
 av_free(src_w);
 return -1;
 }
-- 
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmp

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

[Fu, Ting]

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 one of FFmpeg DNN 
backend, would help the PyTorch users a lot.

PS, ONNX is not in my plan. I am going to improve the LibTorch backend 
performance and make it compatible with more models in next steps.

Thank you.
Ting FU

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Jean-Baptiste Kempf
> Sent: Monday, May 23, 2022 05:51 PM
> To: ffmpeg-devel 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] libavfi/dnn: add LibTorch as one of
> DNN backend
> 
> Hello,
> 
> Are we seriously going to add all backends for ML in FFmpeg? Next one is
> ONNNX?
> 
> jb
> 
> On Mon, 23 May 2022, at 11:29, Ting Fu wrote:
> > PyTorch is an open source machine learning framework that accelerates
> > the path from research prototyping to production deployment. Official
> > websit: https://pytorch.org/. We call the C++ library of PyTorch as
> > LibTorch, the same below.
> >
> > To build FFmpeg with LibTorch, please take following steps as reference:
> > 1. download LibTorch C++ library in
> > https://pytorch.org/get-started/locally/,
> > please select C++/Java for language, and other options as your need.
> > 2. unzip the file to your own dir, with command unzip
> > libtorch-shared-with-deps-latest.zip -d your_dir 3. export
> > libtorch_root/libtorch/include and
> > libtorch_root/libtorch/include/torch/csrc/api/include to $PATH export
> > libtorch_root/libtorch/lib/ to $LD_LIBRARY_PATH 4. config FFmpeg with
> > ../configure --enable-libtorch
> > --extra-cflag=-I/libtorch_root/libtorch/include
> > --extra-cflag=-I/libtorch_root/libtorch/include/torch/csrc/api/include
> > --extra-ldflags=-L/libtorch_root/libtorch/lib/
> > 5. make
> >
> > To run FFmpeg DNN inference with LibTorch backend:
> > ./ffmpeg -i input.jpg -vf
> > dnn_processing=dnn_backend=torch:model=LibTorch_model.pt -y
> output.jpg
> > The LibTorch_model.pt can be generated by Python with
> > torch.jit.script() api. Please note, torch.jit.trace() is not
> > recommanded, since it does not support ambiguous input size.
> >
> > Signed-off-by: Ting Fu 
> > ---
> >  configure |   7 +-
> >  libavfilter/dnn/Makefile  |   1 +
> >  libavfilter/dnn/dnn_backend_torch.cpp | 567
> ++
> >  libavfilter/dnn/dnn_backend_torch.h   |  47 +++
> >  libavfilter/dnn/dnn_interface.c   |  12 +
> >  libavfilter/dnn/dnn_io_proc.c | 117 +-
> >  libavfilter/dnn_filter_common.c   |  31 +-
> >  libavfilter/dnn_interface.h   |   3 +-
> >  libavfilter/vf_dnn_processing.c   |   3 +
> >  9 files changed, 774 insertions(+), 14 deletions(-)  create mode
> > 100644 libavfilter/dnn/dnn_backend_torch.cpp
> >  create mode 100644 libavfilter/dnn/dnn_backend_torch.h
> >
> > diff --git a/configure b/configure
> > index f115b21064..85ce3e67a3 100755
> > --- a/configure
> > +++ b/configure
> > @@ -279,6 +279,7 @@ External library support:
> >--enable-libtheora   enable Theora encoding via libtheora [no]
> >--enable-libtls  enable LibreSSL (via libtls), needed for
> > https support
> > if openssl, gnutls or mbedtls is not used
> > [no]
> > +  --enable-libtorchenable Torch as one DNN backend
> >--enable-libtwolame  enable MP2 encoding via libtwolame [no]
> >--enable-libuavs3d   enable AVS3 decoding via libuavs3d [no]
> >--enable-libv4l2 enable libv4l2/v4l-utils [no]
> > @@ -1850,6 +1851,7 @@ EXTERNAL_LIBRARY_LIST="
> >  libopus
> >  libplacebo
> >  libpulse
> > +libtorch
> >  librabbitmq
> >  librav1e
> >  librist
> > @@ -2719,7 +2721,7 @@ dct_select="rdft"
> >  deflate_wrapper_deps="zlib"
> >  dirac_parse_select="golomb"
> >  dovi_rpu_select="golomb"
> > -dnn_suggest="libtensorflow libopenvino"
> > +dnn_suggest="libtensorflow libopenvino libtorch"
> >  dnn_deps="avformat swscale"
> >  error_resilience_select="me_cmp"
> >  faandct_deps="faan"
> > @@ -6600,6 +6602,7 @@ enabled libopus   && {
> >  }
> >  enabled libplacebo&& require_pkg_config libplacebo "libplacebo
> > >= 4.192.0" libplacebo/vulkan.h pl_vulkan_create
> >  enabled libpulse  && require_pkg_config libpulse libpulse
> > pulse/pulseaudio.h pa_context_new
> > +enabled libtorch  && add_cppflags -D_GLIBCXX_USE_CXX11_ABI=0
> > && check_cxxflags -std=c++14 && require_cpp libtorch torch/torch.h
> > "torch::Tensor" -ltorch -lc10 -ltorch_cpu -lstdc++ -lpthread
> >  enabled librabbitmq   && require_pkg_config librabbitmq
> > "librabbitmq >= 0.7.1" amqp.h amqp_new_connection
> >  enabled librav1e  && require_pkg_config librav1e "rav1e >=
> > 0.4.0" rav1e.h rav1e_context_new
> >  enabled librist   && require_p

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

[Soft Works]

> -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 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 one
> of FFmpeg DNN backend, would help the PyTorch users a lot.
> 
> PS, ONNX is not in my plan. I am going to improve the LibTorch backend
> performance and make it compatible with more models in next steps.
> 
> Thank you.
> Ting FU

Hi Ting,

I've never looked at the DNN part in ffmpeg, so just out of curiosity:

Is this working 1-way or 2-way? What I mean is whether this is just about
feeding images to the AI engines or does the ffmpeg filter get some data
in return for each frame that is processed?

So for example, in case of object identification/tracking, is it possible
to get identified rectangles back from the inference result, attach it to
an AVFrame so that a downstream filter could paint those rectangles on
each video frame?

Thanks,
softworkz



___
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] libavfi/dnn: add LibTorch as one of DNN backend

[Jean-Baptiste Kempf]

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. 
Those are not to support different hardware, but different tastes for users, 
who prefer one API to another one.
Where does it end? How many of those backends will we get? 10?

What's the value to do that development inside ffmpeg?

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
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 v4 1/1] avutil/csp: create public API for colorspace structs

[Anton Khirnov]

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.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVUTIL_CSP_H
> +#define AVUTIL_CSP_H
> +
> +#include "pixfmt.h"
> +#include "rational.h"
> +
> +#define AVUTIL_CSP_DENOM 10

This should be documented.

> +
> +typedef struct AVLumaCoefficients {
> +AVRational cr, cg, cb;
> +} AVLumaCoefficients;
> +
> +typedef struct AVCIExy {
> +AVRational x, y;
> +} AVCIExy;
> +
> +typedef struct AVPrimaryCoefficients {
> +AVCIExy r, g, b;
> +} AVPrimaryCoefficients;
> +
> +typedef AVCIExy AVWhitepointCoefficients;
> +
> +typedef struct AVColorPrimariesDesc {
> +AVWhitepointCoefficients wp;
> +AVPrimaryCoefficients prim;
> +} AVColorPrimariesDesc;
> +
> +/* Returns AVCOL_PRI_UNSPECIFIED if no clear match can be identified */
> +enum AVColorPrimaries av_detect_color_primaries(const AVColorPrimariesDesc 
> *prm);
> +
> +const AVColorPrimariesDesc *av_get_color_primaries(enum AVColorPrimaries 
> prm);
> +const AVLumaCoefficients *av_get_luma_coefficients(enum AVColorSpace csp);

The names should be consistently namespaced along the lines of
av__(). E.g.
av_csp_primaries_desc_from_id()/av_csp_primaries_id_from_desc()

-- 
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 v4 1/1] avutil/csp: create public API for colorspace structs

[Vittorio Giovara]

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 regression testing easier and
> more consistent
>

which places did you have in mind to use this api in avcodec and avformat?
also wouldn't callers be interested in accessory functions like
ff_matrix_invert_3x3 if they are dealing with color spaces?
-- 
Vittorio
___
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] libavfi/dnn: add LibTorch as one of DNN backend

[Soft Works]

> -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 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.
> Those are not to support different hardware, but different tastes for
> users, who prefer one API to another one.

It's not just about taste. Many models can only work with a specific
backend and converting is often between difficult and impossible.


> Where does it end? How many of those backends will we get? 10?

>From my pov, the best solution not only for this but also for other 
use cases would be - as suggested a while ago - a plug-in model
for filters.


> What's the value to do that development inside ffmpeg?

That's connected to my question about 1-way or 2-way interaction
with those APIs.

When it's just about feeding video frames into such APIs, then
there wouldn't be much reason for having this integrated into
ffmpeg.

But as soon as you want to make modifications to video frames,
how could it be implemented otherwise? I mean, none of those
APIs are capable to do video processing like ffmpeg can do.

In any case, there needs to be some way to interact with those 
APIs and at both sides, at a certain point, you need to have
uncompressed images to work with, and when that memory could
be shared between ffmpeg and the AI API, it saves memory
and you get rid of encoding/decoding and load/save for
sharing the image between ffmpeg and the AI api.
Also, that kind of integration allows processing with 
lower latency, which is crucial when working with
live video.

I've never used it like this, but I'm sure I will.

Kind regards,
softworkz



___
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 v4 1/1] avutil/csp: create public API for colorspace structs

[Leo Izen]

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 libavformat. It also converts those structs from
double values to AVRational to make regression testing easier and
more consistent


which places did you have in mind to use this api in avcodec and avformat?
also wouldn't callers be interested in accessory functions like 
ff_matrix_invert_3x3 if they are dealing with color spaces?

--
Vittorio


Once this is merged I plan on using it in the libjxl encoder wrapper. As 
for the other functions, they aren't needed at this time but they could 
always be exported at a later date if required.


- Leo Izen (thebombzen)
___
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 v5 0/1] avutil/csp: create public API for colorspace structs

[Leo Izen]

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 namespace them via av_csp_,
  as requested by Anton K
- documented public API using Doxygen comments
- remove abs() from denominator in abs_sub_q, assuming denom is positive,
  as requested by Andreas R

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
- add 0.5 to the AVR macro definition to get exact values from truncation

Leo Izen (1):
  avutil/csp: create public API for colorspace structs

 libavfilter/colorspace.c| 143 
 libavfilter/colorspace.h|  31 +---
 libavfilter/fflcms2.c   |  33 +
 libavfilter/fflcms2.h   |   4 +-
 libavfilter/vf_colorspace.c |  37 +-
 libavfilter/vf_iccdetect.c  |   5 +-
 libavfilter/vf_tonemap.c|  17 +
 libavutil/Makefile  |   2 +
 libavutil/csp.c | 128 
 libavutil/csp.h | 115 +
 libavutil/version.h |   2 +-
 11 files changed, 326 insertions(+), 191 deletions(-)
 create mode 100644 libavutil/csp.c
 create mode 100644 libavutil/csp.h

-- 
2.36.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 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 consistent.
---
 libavfilter/colorspace.c| 143 
 libavfilter/colorspace.h|  31 +---
 libavfilter/fflcms2.c   |  33 +
 libavfilter/fflcms2.h   |   4 +-
 libavfilter/vf_colorspace.c |  37 +-
 libavfilter/vf_iccdetect.c  |   5 +-
 libavfilter/vf_tonemap.c|  17 +
 libavutil/Makefile  |   2 +
 libavutil/csp.c | 128 
 libavutil/csp.h | 115 +
 libavutil/version.h |   2 +-
 11 files changed, 326 insertions(+), 191 deletions(-)
 create mode 100644 libavutil/csp.c
 create mode 100644 libavutil/csp.h

diff --git a/libavfilter/colorspace.c b/libavfilter/colorspace.c
index 8d7b882375..7f74fe5113 100644
--- a/libavfilter/colorspace.c
+++ b/libavfilter/colorspace.c
@@ -65,24 +65,28 @@ void ff_matrix_mul_3x3(double dst[3][3],
 /*
  * see e.g. http://www.brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html
  */
-void ff_fill_rgb2xyz_table(const struct PrimaryCoefficients *coeffs,
-   const struct WhitepointCoefficients *wp,
+void ff_fill_rgb2xyz_table(const AVPrimaryCoefficients *coeffs,
+   const AVWhitepointCoefficients *wp,
double rgb2xyz[3][3])
 {
 double i[3][3], sr, sg, sb, zw;
-
-rgb2xyz[0][0] = coeffs->xr / coeffs->yr;
-rgb2xyz[0][1] = coeffs->xg / coeffs->yg;
-rgb2xyz[0][2] = coeffs->xb / coeffs->yb;
+double xr = av_q2d(coeffs->r.x), yr = av_q2d(coeffs->r.y);
+double xg = av_q2d(coeffs->g.x), yg = av_q2d(coeffs->g.y);
+double xb = av_q2d(coeffs->b.x), yb = av_q2d(coeffs->b.y);
+double xw = av_q2d(wp->x), yw = av_q2d(wp->y);
+
+rgb2xyz[0][0] = xr / yr;
+rgb2xyz[0][1] = xg / yg;
+rgb2xyz[0][2] = xb / yb;
 rgb2xyz[1][0] = rgb2xyz[1][1] = rgb2xyz[1][2] = 1.0;
-rgb2xyz[2][0] = (1.0 - coeffs->xr - coeffs->yr) / coeffs->yr;
-rgb2xyz[2][1] = (1.0 - coeffs->xg - coeffs->yg) / coeffs->yg;
-rgb2xyz[2][2] = (1.0 - coeffs->xb - coeffs->yb) / coeffs->yb;
+rgb2xyz[2][0] = (1.0 - xr - yr) / yr;
+rgb2xyz[2][1] = (1.0 - xg - yg) / yg;
+rgb2xyz[2][2] = (1.0 - xb - yb) / yb;
 ff_matrix_invert_3x3(rgb2xyz, i);
-zw = 1.0 - wp->xw - wp->yw;
-sr = i[0][0] * wp->xw + i[0][1] * wp->yw + i[0][2] * zw;
-sg = i[1][0] * wp->xw + i[1][1] * wp->yw + i[1][2] * zw;
-sb = i[2][0] * wp->xw + i[2][1] * wp->yw + i[2][2] * zw;
+zw = 1.0 - xw - yw;
+sr = i[0][0] * xw + i[0][1] * yw + i[0][2] * zw;
+sg = i[1][0] * xw + i[1][1] * yw + i[1][2] * zw;
+sb = i[2][0] * xw + i[2][1] * yw + i[2][2] * zw;
 rgb2xyz[0][0] *= sr;
 rgb2xyz[0][1] *= sg;
 rgb2xyz[0][2] *= sb;
@@ -107,119 +111,32 @@ static const double gbr_matrix[3][3] =
 { 0.5, -0.5, 0   },
 };
 
-/*
- * All constants explained in e.g. 
https://linuxtv.org/downloads/v4l-dvb-apis/ch02s06.html
- * The older ones (bt470bg/m) are also explained in their respective ITU docs
- * (e.g. 
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.470-5-199802-S!!PDF-E.pdf)
- * whereas the newer ones can typically be copied directly from wikipedia :)
- */
-static const struct LumaCoefficients luma_coefficients[AVCOL_SPC_NB] = {
-[AVCOL_SPC_FCC]= { 0.30,   0.59,   0.11   },
-[AVCOL_SPC_BT470BG]= { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_SMPTE170M]  = { 0.299,  0.587,  0.114  },
-[AVCOL_SPC_BT709]  = { 0.2126, 0.7152, 0.0722 },
-[AVCOL_SPC_SMPTE240M]  = { 0.212,  0.701,  0.087  },
-[AVCOL_SPC_YCOCG]  = { 0.25,   0.5,0.25   },
-[AVCOL_SPC_RGB]= { 1,  1,  1  },
-[AVCOL_SPC_BT2020_NCL] = { 0.2627, 0.6780, 0.0593 },
-[AVCOL_SPC_BT2020_CL]  = { 0.2627, 0.6780, 0.0593 },
-};
-
-const struct LumaCoefficients *ff_get_luma_coefficients(enum AVColorSpace csp)
-{
-const struct LumaCoefficients *coeffs;
-
-if (csp >= AVCOL_SPC_NB)
-return NULL;
-coeffs = &luma_coefficients[csp];
-if (!coeffs->cr)
-return NULL;
-
-return coeffs;
-}
-
-#define WP_D65 { 0.3127, 0.3290 }
-#define WP_C   { 0.3100, 0.3160 }
-#define WP_DCI { 0.3140, 0.3510 }
-#define WP_E   { 1/3.0f, 1/3.0f }
-
-static const struct ColorPrimaries color_primaries[AVCOL_PRI_NB] = {
-[AVCOL_PRI_BT709] = { WP_D65, { 0.640, 0.330, 0.300, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_BT470M]= { WP_C,   { 0.670, 0.330, 0.210, 0.710, 0.140, 
0.080 } },
-[AVCOL_PRI_BT470BG]   = { WP_D65, { 0.640, 0.330, 0.290, 0.600, 0.150, 
0.060 } },
-[AVCOL_PRI_SMPTE170M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-[AVCOL_PRI_SMPTE240M] = { WP_D65, { 0.630, 0.340, 0.310, 0.595, 0.155, 
0.070 } },
-   

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

[Andreas Rheinhardt]

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
> --- a/libavcodec/vc1_loopfilter.c
> +++ b/libavcodec/vc1_loopfilter.c
> @@ -1125,10 +1125,7 @@ static av_always_inline void 
> vc1_b_h_intfi_loop_filter(VC1Context *v, uint8_t *d
>  dst = dest + (block_num & 2) * 4 * s->linesize + (block_num & 1) * 8;
>  
>  if (!(flags & RIGHT_EDGE) || !(block_num & 5)) {
> -if (block_num > 3)
> -v->vc1dsp.vc1_h_loop_filter8(dst + 8, linesize, pq);
> -else
> -v->vc1dsp.vc1_h_loop_filter8(dst + 8, linesize, pq);
> +v->vc1dsp.vc1_h_loop_filter8(dst + 8, linesize, pq);
>  }
>  
>  tt = ttblk[0] >> (block_num * 4) & 0xf;

Are you certain that the current code is actually correct or whether
something else was intended?

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

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

[Soft Works]

> -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:
> 
> > 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 do that later at some point, but I don't see it as
> urgent.
> 
> > - I have kept the path functions in the same way like .NET does it,
> >  just for easy reference and following. Compilers will inline
> >  them anyway (my pov). Maybe others don't like that. I can change
> >  if it's got to be.
> 
> Having the individual functions inline compared to merging it all in one
> big function doesn't matter to me. But the amount of code in this inline
> header is growing a bit big, to the point that I think it is measurable
> when multiple files within the same library use these functions. Longer
> term, it would probably make sense to make them more shared in some way.

> If C would have the C++ style deduplication feature for non-static inline
> functions, this wouldn't be an issue. One could consider making them ff_
> functions and carry a copy in each library too, maybe. (But that also
> makes it trickier to use in fftools.) 

A copy in each library - isn't that exactly what's already happening?

The get_extended_win32_path() is used from 2 places:

1. file_open.c

For this, we already have copies in each library. file_open.c includes
wchar_filename.h and the new functions are inlined into file_open.obj.
So, there's only one copy in each library

2. os_support.h

This is used in libavformat exclusively. But in this case, the code gets
duplicated actually for each consumption of one of those file functions.
There aren't many usages in total, though, and I don't see any trend 
on the horizon for sudden increase, so I agree that there's no urgency.


BTW, thanks for your other comments, I have added the missing av_free()
calls and included URLs to the .NET source.
I chose to use permalinks. These are long and ugly, but they have changed
their structure (and even repo) so often during the past years, that
chances are low that the non-versioned links would still be valid in a
few years (I wouldn't even bet on months :-)

softworkz








___
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/3] fftools: Stop using av_fopen_utf8

[Martin Storsjö]

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, 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 do that later at some point, but I don't see it as
urgent.


- I have kept the path functions in the same way like .NET does it,
 just for easy reference and following. Compilers will inline
 them anyway (my pov). Maybe others don't like that. I can change
 if it's got to be.


Having the individual functions inline compared to merging it all in one
big function doesn't matter to me. But the amount of code in this inline
header is growing a bit big, to the point that I think it is measurable
when multiple files within the same library use these functions. Longer
term, it would probably make sense to make them more shared in some way.



If C would have the C++ style deduplication feature for non-static inline
functions, this wouldn't be an issue. One could consider making them ff_
functions and carry a copy in each library too, maybe. (But that also
makes it trickier to use in fftools.)


A copy in each library - isn't that exactly what's already happening?

The get_extended_win32_path() is used from 2 places:

2. os_support.h

This is used in libavformat exclusively. But in this case, the code gets
duplicated actually for each consumption of one of those file functions.
There aren't many usages in total, though, and I don't see any trend
on the horizon for sudden increase, so I agree that there's no urgency.


Yes, this is what I was referring to. It's clearly more than one use. When 
counting files that use mkdir, unlink or "struct stat", I find around 9 
individual .c files in libavformat, that would end up with static inline 
copies of all of this.


Compared with the av_fopen_utf8 case, I first tested fixing it by making 
it a static inline function in a libavutil header, but that did increase 
the size of a built DLL by a couple KB. I guess this increases it by a 
bit more than that.


It's still not a lot, and this isn't a blocker (and I probably prefer that 
we don't try to redesign this issue here now, in order not to drag out the 
review further), but compared to how C++ inline methods are deduplicated 
by the linker, it's a slightly annoying inefficiency.


// Martin
___
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] checkasm: improve hevc_sao test

[Martin Storsjö]

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 ---
1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/tests/checkasm/hevc_sao.c b/tests/checkasm/hevc_sao.c
index 6b750758e2..72cdb87dd1 100644
--- a/tests/checkasm/hevc_sao.c
+++ b/tests/checkasm/hevc_sao.c
@@ -78,20 +78,26 @@ static void check_sao_band(HEVCDSPContext h, int bit_depth)

for (i = 0; i <= 4; i++) {
int block_size = sao_size[i];
+int prev_size = i > 0 ? sao_size[i - 1] : 0;
ptrdiff_t stride = PIXEL_STRIDE*SIZEOF_PIXEL;
declare_func_emms(AV_CPU_FLAG_MMX, void, uint8_t *dst, uint8_t *src, 
ptrdiff_t dst_stride, ptrdiff_t src_stride,
  int16_t *sao_offset_val, int sao_left_class, int 
width, int height);

-randomize_buffers(src0, src1, BUF_SIZE);
-randomize_buffers2(offset_val, OFFSET_LENGTH);
-memset(dst0, 0, BUF_SIZE);
-memset(dst1, 0, BUF_SIZE);
-
-if (check_func(h.sao_band_filter[i], "hevc_sao_band_%dx%d_%d", 
block_size, block_size, bit_depth)) {
-call_ref(dst0, src0, stride, stride, offset_val, left_class, 
block_size, block_size);
-call_new(dst1, src1, stride, stride, offset_val, left_class, 
block_size, block_size);
-if (memcmp(dst0, dst1, BUF_SIZE))
-fail();
+if (check_func(h.sao_band_filter[i], "hevc_sao_band_%d_%d", 
block_size, bit_depth)) {
+
+for (int w = prev_size + 4; w <= block_size; w += 4) {
+randomize_buffers(src0, src1, BUF_SIZE);
+randomize_buffers2(offset_val, OFFSET_LENGTH);
+memset(dst0, 0, BUF_SIZE);
+memset(dst1, 0, BUF_SIZE);
+
+call_ref(dst0, src0, stride, stride, offset_val, left_class, 
w, block_size);
+call_new(dst1, src1, stride, stride, offset_val, left_class, 
w, block_size);
+for (int j = 0; j < block_size; j++) {
+if (memcmp(dst0 + j*MAX_PB_SIZE*2, dst1 + j*MAX_PB_SIZE*2, 
w))


I'm not quite sure about the MAX_PB_SIZE*2 part here - shouldn't that be 
just the 'stride' variable instead? And for the compared length ('w'), 
shouldn't that be multiplied by SIZEOF_PIXEL?


Other than that, this looks good to me!

// Martin

___
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/3] fftools: Stop using av_fopen_utf8

[Soft Works]

> -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:
> 
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of
> Martin
> >> Storsjö
> >> Sent: Tuesday, May 24, 2022 11:29 AM
> >> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> >> Subject: 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 do that later at some point, but I don't see it as
> >> urgent.
> >>
> >>> - I have kept the path functions in the same way like .NET does it,
> >>>  just for easy reference and following. Compilers will inline
> >>>  them anyway (my pov). Maybe others don't like that. I can change
> >>>  if it's got to be.
> >>
> >> Having the individual functions inline compared to merging it all in
> one
> >> big function doesn't matter to me. But the amount of code in this
> inline
> >> header is growing a bit big, to the point that I think it is measurable
> >> when multiple files within the same library use these functions. Longer
> >> term, it would probably make sense to make them more shared in some
> way.
> >
> >> If C would have the C++ style deduplication feature for non-static
> inline
> >> functions, this wouldn't be an issue. One could consider making them
> ff_
> >> functions and carry a copy in each library too, maybe. (But that also
> >> makes it trickier to use in fftools.)
> >
> > A copy in each library - isn't that exactly what's already happening?
> >
> > The get_extended_win32_path() is used from 2 places:
> >
> > 2. os_support.h
> >
> > This is used in libavformat exclusively. But in this case, the code gets
> > duplicated actually for each consumption of one of those file functions.
> > There aren't many usages in total, though, and I don't see any trend
> > on the horizon for sudden increase, so I agree that there's no urgency.
> 
> Yes, this is what I was referring to. It's clearly more than one use. When
> counting files that use mkdir, unlink or "struct stat", I find around 9
> individual .c files in libavformat, that would end up with static inline
> copies of all of this.
> 
> Compared with the av_fopen_utf8 case, I first tested fixing it by making
> it a static inline function in a libavutil header, but that did increase
> the size of a built DLL by a couple KB. I guess this increases it by a
> bit more than that.
> 
> It's still not a lot, and this isn't a blocker (and I probably prefer that
> we don't try to redesign this issue here now, in order not to drag out the
> review further)

I'm glad you're saying that ;-)

It probably won't be difficult to improve this in a future change, making it
a wchar_filename.c plus wchar_filename.h file in libavutil. If I'm not 
mistaken, there shouldn't be an issue with multiple CRTs as memory is 
managed by av_ functions?

Thanks,
sw


___
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/3] fftools: Stop using av_fopen_utf8

[Martin Storsjö]

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, 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 
de...@ffmpeg.org>

Subject: 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 do that later at some point, but I don't see it as
urgent.


- I have kept the path functions in the same way like .NET does it,
 just for easy reference and following. Compilers will inline
 them anyway (my pov). Maybe others don't like that. I can change
 if it's got to be.


Having the individual functions inline compared to merging it all in

one

big function doesn't matter to me. But the amount of code in this

inline

header is growing a bit big, to the point that I think it is measurable
when multiple files within the same library use these functions. Longer
term, it would probably make sense to make them more shared in some

way.



If C would have the C++ style deduplication feature for non-static

inline

functions, this wouldn't be an issue. One could consider making them

ff_

functions and carry a copy in each library too, maybe. (But that also
makes it trickier to use in fftools.)


A copy in each library - isn't that exactly what's already happening?

The get_extended_win32_path() is used from 2 places:

2. os_support.h

This is used in libavformat exclusively. But in this case, the code gets
duplicated actually for each consumption of one of those file functions.
There aren't many usages in total, though, and I don't see any trend
on the horizon for sudden increase, so I agree that there's no urgency.


Yes, this is what I was referring to. It's clearly more than one use. When
counting files that use mkdir, unlink or "struct stat", I find around 9
individual .c files in libavformat, that would end up with static inline
copies of all of this.

Compared with the av_fopen_utf8 case, I first tested fixing it by making
it a static inline function in a libavutil header, but that did increase
the size of a built DLL by a couple KB. I guess this increases it by a
bit more than that.

It's still not a lot, and this isn't a blocker (and I probably prefer that
we don't try to redesign this issue here now, in order not to drag out the
review further)


I'm glad you're saying that ;-)

It probably won't be difficult to improve this in a future change, making it
a wchar_filename.c plus wchar_filename.h file in libavutil. If I'm not
mistaken, there shouldn't be an issue with multiple CRTs as memory is
managed by av_ functions?


Indeed, that's not a problem for plain filename conversions. The main 
hesitation is that we'd generally want to avoid adding more avpriv_ APIs 
unless strictly necessary.


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

[Martin Storsjö]

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

___
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 v5 1/1] avutil/csp: create public API for colorspace structs

[Andreas Rheinhardt]

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 consistent.
> ---
>  libavfilter/colorspace.c| 143 
>  libavfilter/colorspace.h|  31 +---
>  libavfilter/fflcms2.c   |  33 +
>  libavfilter/fflcms2.h   |   4 +-
>  libavfilter/vf_colorspace.c |  37 +-
>  libavfilter/vf_iccdetect.c  |   5 +-
>  libavfilter/vf_tonemap.c|  17 +
>  libavutil/Makefile  |   2 +
>  libavutil/csp.c | 128 
>  libavutil/csp.h | 115 +
>  libavutil/version.h |   2 +-
>  11 files changed, 326 insertions(+), 191 deletions(-)
>  create mode 100644 libavutil/csp.c
>  create mode 100644 libavutil/csp.h
> > diff --git a/libavutil/csp.h b/libavutil/csp.h
> new file mode 100644
> index 00..57a615c678
> --- /dev/null
> +++ b/libavutil/csp.h
> @@ -0,0 +1,115 @@
> +/*
> + * Copyright (c) 2016 Ronald S. Bultje 
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVUTIL_CSP_H
> +#define AVUTIL_CSP_H
> +
> +#include "pixfmt.h"
> +#include "rational.h"
> +
> +/**
> + * @file Colorspace value utility functions for libavutil.
> + * @author Ronald S. Bultje 
> + * @author Leo Izen 
> + * @defgroup lavu_math_csp Colorspace Utility
> + * @ingroup lavu_math
> + * @{
> + */
> +
> +/**
> + * This denominator should be used when converting float or double values to
> + * AVRational so they can work with this API, because it provides significant
> + * enough precision to be visually identical to the floating point values.
> + * @see av_d2q()
> + */
> +#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.)

> +
> +/**
> + * Struct containing luma coefficients to be used for RGB to YUV 
> calculations,
> + * or YUV to RGB.
> + */
> +typedef struct AVLumaCoefficients {
> +AVRational cr, cg, cb;
> +} AVLumaCoefficients;
> +
> +/**
> + * Struct containing chromaticity x and y values for the standard CIE 1931
> + * chromaticity definition.
> + */
> +typedef struct AVCIExy {
> +AVRational x, y;
> +} AVCIExy;
> +
> +/**
> + * Struct defining the red, green, and blue primary locations in terms of CIE
> + * 1931 chromaticity x and y.
> + */
> +typedef struct AVPrimaryCoefficients {
> +AVCIExy r, g, b;
> +} AVPrimaryCoefficients;
> +
> +/**
> + * Struct defining white point location in terms of CIE 1931 chromaticity x
> + * and y.
> + */
> +typedef AVCIExy AVWhitepointCoefficients;
> +
> +/**
> + * Struct that contains both white point location and primaries location, 
> providing
> + * the complete description of a color gamut.
> + */
> +typedef struct AVColorPrimariesDesc {
> +AVWhitepointCoefficients wp;
> +AVPrimaryCoefficients prim;
> +} AVColorPrimariesDesc;
> +
> +
> +/**
> + * Detects which enum AVColorPrimaries constant corresponds to the given 
> complete
> + * gamut description.
> + * @see enum AVColorPrimaries
> + * @param prm A description of the colorspace gamut
> + * @return The enum constant associated with this gamut, or
> + * AVCOL_PRI_UNSPECIFIED if no clear match can be idenitified.
> + */
> +enum AVColorPrimaries av_csp_primaries_id_from_desc(const 
> AVColorPrimariesDesc *prm);
> +
> +/**
> + * Retrieves a complete gamut description from an enum constant describing 
> the
> + * color primaries.
> + * @param prm An enum constant indicating primaries
> + * @return A description of the colorspace gamut associated with that enum
> + * constant, or NULL if the constant is unknown to libavutil.
> + */
> +const AVColorPrimariesDesc *av_csp_primaries_desc_from_id(enum 
> AVColorPrimaries prm);
> +
> +/**
> + * Retrieves the Luma coefficients necessary to construct a conversion matrix
> + * from an enum constant describing the YUV colorspace.
> + * @param csp An enum constant indicating YUV colorspace.
> + * @return The Luma coeffic

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

[Martin Storsjö]

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..179b926293 100644
--- a/libavformat/os_support.h
+++ b/libavformat/os_support.h
@@ -49,7 +49,24 @@
#  ifdef stat
#   undef stat
#  endif
-#  define stat _stati64
+
+#  define stat win32_stat
+
+struct win32_stat
+{
+_dev_t st_dev; /* ID of device containing file */
+_ino_t st_ino; /* inode number */
+unsigned short st_mode;/* protection */
+short  st_nlink;   /* number of hard links */
+short  st_uid; /* user ID of owner */
+short  st_gid; /* group ID of owner */
+_dev_t st_rdev;/* device ID (if special file) */
+long   st_size;/* total size, in bytes */
+time_t st_atime;   /* time of last access */
+time_t st_mtime;   /* time of last modification */
+time_t st_ctime;   /* time of last status change */
+};


Please use int64_t for both st_size and st_?time. We already use _stati64 
so far, so we get 64 bit sizes (and long definitely isn't a 64 bit type on 
Windows!), and with int64_t in the outer struct, we won't accidentally 
truncate any valid data that we got from the lower level stat function 
call.





+
#  ifdef fstat
#   undef fstat
#  endif
@@ -153,7 +170,7 @@ static inline int win32_##name(const char *filename_utf8) \
wchar_t *filename_w;  \
int ret;  \
  \
-if (utf8towchar(filename_utf8, &filename_w))  \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
return -1;\
if (!filename_w)  \
goto fallback;\
@@ -171,37 +188,59 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)

-#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
-static inline int win32_##name(const char *filename_utf8, partype par) \
-{ \
-wchar_t *filename_w;  \
-int ret;  \
-  \
-if (utf8towchar(filename_utf8, &filename_w))  \
-return -1;\
-if (!filename_w)  \
-goto fallback;\
-  \
-ret = wfunc(filename_w, par); \
-av_free(filename_w);  \
-return ret;   \
-  \
-fallback: \
-/* filename may be be in CP_ACP */\
-return afunc(filename_utf8, par); \
+static inline int win32_access(const char *filename_utf8, int par)
+{
+wchar_t *filename_w;
+int ret;
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+if (!filename_w)
+goto fallback;
+ret = _waccess(filename_w, par);
+av_free(filename_w);
+return ret;
+fallback:
+return _access(filename_utf8, par);
}

-DEF_FS_FUNCTION2(access, _waccess, _access, int)
-DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
+static inline int win32_stat(const char *filename_utf8, struct stat *par)
+{


Maybe "struct win32_stat" in the parameter here too, for consistency?


+wchar_t *filename_w;
+int ret;
+struct _stati64 winstat = { 0 };
+
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+
+if (filename_w) {
+ret = _wstat64(filename_w, &winstat);
+av_free(filename_w);
+} else
+ret = _stat64(filename_utf8, &winstat);
+
+par->st_dev   = winstat.st_dev;
+par->st_ino   = winstat.st_ino;
+par->st_mode  = winstat.st_mode;
+par->st_nlink = winstat.st_nlink;
+par->st_uid   = winstat.st_uid;
+par->st_gid   = winstat.st_gid;
+par->st_rdev  = winstat.st_rdev;
+par->st_size  = winstat.st_size;
+par->st_atime = winstat.st_atime;
+par->st_mtime = winstat.st_mtime;
+par->st_ctime = winstat.st_ctime;


Thanks, this approach seems robust and safe to me!

With this change in place, shouldn't we drop the #ifdef for 
stat/win32_stat in file.c at the same time?


Other than that, this starts to look ok now.

// Martin

__

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

[Leo Izen]

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 be (and 
is) manually coded as {1, 3} without using the macro. The spec defines 
it as one-third exactly, not via a float value. Adding a factor of 3 to 
every denominator shouldn't be necessary as the various av_q functions 
handle that gracefully already.


-Leo Izen (thebombzen)
___
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 2/2] avformat/os_support: Support long file names on Windows

[Soft Works]

> -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 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..179b926293 100644
> > --- a/libavformat/os_support.h
> > +++ b/libavformat/os_support.h
> > @@ -49,7 +49,24 @@
> > #  ifdef stat
> > #   undef stat
> > #  endif
> > -#  define stat _stati64
> > +
> > +#  define stat win32_stat
> > +
> > +struct win32_stat
> > +{
> > +_dev_t st_dev; /* ID of device containing file */
> > +_ino_t st_ino; /* inode number */
> > +unsigned short st_mode;/* protection */
> > +short  st_nlink;   /* number of hard links */
> > +short  st_uid; /* user ID of owner */
> > +short  st_gid; /* group ID of owner */
> > +_dev_t st_rdev;/* device ID (if special file) */
> > +long   st_size;/* total size, in bytes */
> > +time_t st_atime;   /* time of last access */
> > +time_t st_mtime;   /* time of last modification */
> > +time_t st_ctime;   /* time of last status change */
> > +};
> 
> Please use int64_t for both st_size and st_?time. We already use _stati64
> so far, so we get 64 bit sizes (and long definitely isn't a 64 bit type on
> Windows!), and with int64_t in the outer struct, we won't accidentally
> truncate any valid data that we got from the lower level stat function
> call.

I came to long by looking up _off_t in the Windows headers, but you are 
right: as we're explicitly using _stat64, we'll get int64 st_size values,
even on 32bit Windows.

Done.

> > +
> > #  ifdef fstat
> > #   undef fstat
> > #  endif
> > @@ -153,7 +170,7 @@ static inline int win32_##name(const char
> *filename_utf8) \
> > wchar_t *filename_w;  \
> > int ret;  \
> >   \
> > -if (utf8towchar(filename_utf8, &filename_w))  \
> > +if (get_extended_win32_path(filename_utf8, &filename_w)) \
> > return -1;\
> > if (!filename_w)  \
> > goto fallback;\
> > @@ -171,37 +188,59 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
> > DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
> > DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)
> >
> > -#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
> > -static inline int win32_##name(const char *filename_utf8, partype par)
> \
> > -{ \
> > -wchar_t *filename_w;  \
> > -int ret;  \
> > -  \
> > -if (utf8towchar(filename_utf8, &filename_w))  \
> > -return -1;\
> > -if (!filename_w)  \
> > -goto fallback;\
> > -  \
> > -ret = wfunc(filename_w, par); \
> > -av_free(filename_w);  \
> > -return ret;   \
> > -  \
> > -fallback: \
> > -/* filename may be be in CP_ACP */\
> > -return afunc(filename_utf8, par); \
> > +static inline int win32_access(const char *filename_utf8, int par)
> > +{
> > +wchar_t *filename_w;
> > +int ret;
> > +if (get_extended_win32_path(filename_utf8, &filename_w))
> > +return -1;
> > +if (!filename_w)
> > +goto fallback;
> > +ret = _waccess(filename_w, par);
> > +av_free(filename_w);
> > +return ret;
> > +fallback:
> > +return _access(filename_utf8, par);
> > }
> >
> > -DEF_FS_FUNCTION2(access, _waccess, _access, int)
> > -DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
> > +static inline int win32_stat(const char *filename_utf8, struct stat
> *par)
> > +{
> 
> Maybe "struct win32_stat" in the parameter here too, for consistency?

Yup. (it didn't work in an earlier iteration, but now it does)


> > +wchar_t *filename_w;
> > +int ret;
> > +struct _stati64 winstat = { 0 };
> > +
> > +   

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

[ffmpegagent]

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,
but in our case, that's not required. Short (8.3) paths are working as well
with the extended path prefix, even when longer than 260.

Successfully tested:

 * Regular paths wth drive letter
 * Regular UNC paths
 * Long paths wth drive letter
 * Long paths wth drive letter and forward slashes
 * Long UNC paths
 * Prefixed paths wth drive letter
 * Prefixed UNC paths

I have kept the individual functions separate on purpose, to make it easy to
compare with the .NET impl. (compilers should inlinie those anyway)

v2

 * wchar_filename: Improve comments and function documentation
 * os_support: adjust defines to use win32_stat

v3

 * removed length check in path_is_extended()
 * added path_is_device_path() check in add_extended_prefix()
 * add_extended_prefix(): clarified doc and add checks
 * clarified string allocation length calculation
 * replaced 260 with MAX_PATH
 * removed redundant checks after normalization

v4

 * rebased. no changes

v5

 * resolved the ugly struct duplication
 * compatible with _USE_32BIT_TIME_T

v6

 * wchar_filename.h: added links to .NET source code
 * wchar_filename.h: free allocations on error
 * os_support.hs: use clean and safe way to redirect stat() calls

v7

 * os_support.h: remapped fstat with win32_stat structure
 * os_support.h: use int64_t for some members
 * avformat/file: remove _WIN32 condition

softworkz (3):
  avutil/wchar_filename,file_open: Support long file names on Windows
  avformat/os_support: Support long file names on Windows
  avformat/file: remove _WIN32 condition

 libavformat/file.c |   4 -
 libavformat/os_support.h   | 106 --
 libavutil/file_open.c  |   2 +-
 libavutil/wchar_filename.h | 180 +
 4 files changed, 262 insertions(+), 30 deletions(-)


base-commit: 6076dbcb55d0c9b6693d1acad12a63f7268301aa
Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-28%2Fsoftworkz%2Fsubmit_long_filenames-v7
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-28/softworkz/submit_long_filenames-v7
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/28

Range-diff vs v6:

 1:  960aa795ff = 1:  960aa795ff avutil/wchar_filename,file_open: Support long 
file names on Windows
 2:  6f8d400db7 ! 2:  7751335906 avformat/os_support: Support long file names 
on Windows
 @@ libavformat/os_support.h
  +short  st_uid; /* user ID of owner */
  +short  st_gid; /* group ID of owner */
  +_dev_t st_rdev;/* device ID (if special file) */
 -+long   st_size;/* total size, in bytes */
 -+time_t st_atime;   /* time of last access */
 -+time_t st_mtime;   /* time of last modification */
 -+time_t st_ctime;   /* time of last status change */
 ++int64_tst_size;/* total size, in bytes */
 ++int64_tst_atime;   /* time of last access */
 ++int64_tst_mtime;   /* time of last modification */
 ++int64_tst_ctime;   /* time of last status change */
  +};
  +
   #  ifdef fstat
   #   undef fstat
   #  endif
 +-#  define fstat(f,s) _fstati64((f), (s))
 ++#  define fstat win32_fstat
 + #endif /* defined(_WIN32) */
 + 
 + 
  @@ libavformat/os_support.h: static inline int win32_##name(const char 
*filename_utf8) \
   wchar_t *filename_w;  \
   int ret;  \
 @@ libavformat/os_support.h: DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
  +return ret;
  +fallback:
  +return _access(filename_utf8, par);
 ++}
 ++
 ++static inline void copy_stat(struct _stati64 *winstat, struct win32_stat 
*par)
 ++{
 ++par->st_dev   = winstat->st_dev;
 ++par->st_ino   = winstat->st_ino;
 ++par->st_mode  = winstat->st_mode;
 ++par->st_nlink = winstat->st_nlink;
 ++par->st_uid   = winstat->st_uid;
 ++par->st_gid   = winstat->st_gid;
 ++par->st_rdev  = winstat->st_rdev;
 ++par->st_size  = winstat->st_size;
 ++par->st_atime = winstat->st_atime;
 ++par->st_mtime = winstat->st_mtime;
 ++par->st_ctime = winstat->st_ctime;
   }
   
  -DEF_FS_FUNCTION2(access, _waccess, _access, int)
  -DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
 -+static inline int win32_stat(const char *filename_utf8, struct stat *par)
 ++static inline int win32_stat(const char *filename_utf8, struct 
win32_stat *par)

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

[softworkz]

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 100644
--- a/libavutil/file_open.c
+++ b/libavutil/file_open.c
@@ -45,7 +45,7 @@ static int win32_open(const char *filename_utf8, int oflag, 
int pmode)
 wchar_t *filename_w;
 
 /* convert UTF-8 to wide chars */
-if (utf8towchar(filename_utf8, &filename_w))
+if (get_extended_win32_path(filename_utf8, &filename_w))
 return -1;
 if (!filename_w)
 goto fallback;
diff --git a/libavutil/wchar_filename.h b/libavutil/wchar_filename.h
index 90f082452c..f36d9dfea3 100644
--- a/libavutil/wchar_filename.h
+++ b/libavutil/wchar_filename.h
@@ -40,6 +40,186 @@ static inline int utf8towchar(const char *filename_utf8, 
wchar_t **filename_w)
 MultiByteToWideChar(CP_UTF8, 0, filename_utf8, -1, *filename_w, num_chars);
 return 0;
 }
+
+/**
+ * Checks for extended path prefixes for which normalization needs to be 
skipped.
+ * see .NET6: PathInternal.IsExtended()
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L165
+ */
+static inline int path_is_extended(const wchar_t *path)
+{
+if (path[0] == L'\\' && (path[1] == L'\\' || path[1] == L'?') && path[2] 
== L'?' && path[3] == L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Checks for a device path prefix.
+ * see .NET6: PathInternal.IsDevice()
+ * we don't check forward slashes and extended paths (as already done)
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L132
+ */
+static inline int path_is_device_path(const wchar_t *path)
+{
+if (path[0] == L'\\' && path[1] == L'\\' && path[2] == L'.' && path[3] == 
L'\\')
+return 1;
+
+return 0;
+}
+
+/**
+ * Performs path normalization by calling GetFullPathNameW().
+ * see .NET6: PathHelper.GetFullPathName()
+ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L70
+ */
+static inline int get_full_path_name(wchar_t **ppath_w)
+{
+int num_chars;
+wchar_t *temp_w;
+
+num_chars = GetFullPathNameW(*ppath_w, 0, NULL, NULL);
+if (num_chars <= 0) {
+errno = EINVAL;
+return -1;
+}
+
+temp_w = (wchar_t *)av_calloc(num_chars, sizeof(wchar_t));
+if (!temp_w) {
+errno = ENOMEM;
+return -1;
+}
+
+num_chars = GetFullPathNameW(*ppath_w, num_chars, temp_w, NULL);
+if (num_chars <= 0) {
+av_free(temp_w);
+errno = EINVAL;
+return -1;
+}
+
+av_freep(ppath_w);
+*ppath_w = temp_w;
+
+return 0;
+}
+
+/**
+ * Normalizes a Windows file or folder path.
+ * Expansion of short paths (with 8.3 path components) is currently omitted
+ * as it is not required for accessing long paths.
+ * see .NET6: PathHelper.Normalize()
+ * 
https://github.com/dotnet/runtime/blob/2a99e18eedabcf1add064c099da59d9301ce45e0/src/libraries/System.Private.CoreLib/src/System/IO/PathHelper.Windows.cs#L25
+ */
+static inline int path_normalize(wchar_t **ppath_w)
+{
+int ret;
+
+if ((ret = get_full_path_name(ppath_w)) < 0)
+return ret;
+
+/* What .NET does at this point is to call 
PathHelper.TryExpandShortFileName()
+ * in case the path contains a '~' character.
+ * We don't need to do this as we don't need to normalize the file name
+ * for presentation, and the extended path prefix works with 8.3 path
+ * components as well
+ */
+return 0;
+}
+
+/**
+ * Adds an extended path or UNC prefix to longs paths or paths ending
+ * with a space or a dot. (' ' or '.').
+ * This function expects that the path has been normalized before by
+ * calling path_normalize() and it doesn't check whether the path is
+ * actually long (> MAX_PATH).
+ * see .NET6: PathInternal.EnsureExtendedPrefix()
+ * 
https://github.com/dotnet/runtime/blob/9260c249140ef90b4299d0fe1aa3037e25228518/src/libraries/Common/src/System/IO/PathInternal.Windows.cs#L107
+ */
+static inline int add_extended_prefix(wchar_t **ppath_w)
+{
+const wchar_t *unc_prefix   = L"?\\UNC\\";
+const wchar_t *extended_path_prefix = L"?\\";
+const wchar_t *path_w   = *ppath_w;
+const size_t len= wcslen(path_w);
+wchar_t *temp_w;
+
+/* We're skipping the check IsPartiallyQualified() because
+ * we expect to have called GetFullPathNameW() already. */
+if (len < 2 || path_is_extended(*ppath_w) || 
path_is_device_path(*ppath_w)) {
+return 0;
+}
+
+if (path_w[0] == L'\\' && path_w[1] == L'\\') {
+/* unc_prefix length is 8 plus 1 for terminating z

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

[softworkz]

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_support.h
+++ b/libavformat/os_support.h
@@ -49,11 +49,28 @@
 #  ifdef stat
 #   undef stat
 #  endif
-#  define stat _stati64
+
+#  define stat win32_stat
+
+struct win32_stat
+{
+_dev_t st_dev; /* ID of device containing file */
+_ino_t st_ino; /* inode number */
+unsigned short st_mode;/* protection */
+short  st_nlink;   /* number of hard links */
+short  st_uid; /* user ID of owner */
+short  st_gid; /* group ID of owner */
+_dev_t st_rdev;/* device ID (if special file) */
+int64_tst_size;/* total size, in bytes */
+int64_tst_atime;   /* time of last access */
+int64_tst_mtime;   /* time of last modification */
+int64_tst_ctime;   /* time of last status change */
+};
+
 #  ifdef fstat
 #   undef fstat
 #  endif
-#  define fstat(f,s) _fstati64((f), (s))
+#  define fstat win32_fstat
 #endif /* defined(_WIN32) */
 
 
@@ -153,7 +170,7 @@ static inline int win32_##name(const char *filename_utf8) \
 wchar_t *filename_w;  \
 int ret;  \
   \
-if (utf8towchar(filename_utf8, &filename_w))  \
+if (get_extended_win32_path(filename_utf8, &filename_w)) \
 return -1;\
 if (!filename_w)  \
 goto fallback;\
@@ -171,37 +188,76 @@ DEF_FS_FUNCTION(unlink, _wunlink, _unlink)
 DEF_FS_FUNCTION(mkdir,  _wmkdir,  _mkdir)
 DEF_FS_FUNCTION(rmdir,  _wrmdir , _rmdir)
 
-#define DEF_FS_FUNCTION2(name, wfunc, afunc, partype) \
-static inline int win32_##name(const char *filename_utf8, partype par) \
-{ \
-wchar_t *filename_w;  \
-int ret;  \
-  \
-if (utf8towchar(filename_utf8, &filename_w))  \
-return -1;\
-if (!filename_w)  \
-goto fallback;\
-  \
-ret = wfunc(filename_w, par); \
-av_free(filename_w);  \
-return ret;   \
-  \
-fallback: \
-/* filename may be be in CP_ACP */\
-return afunc(filename_utf8, par); \
+static inline int win32_access(const char *filename_utf8, int par)
+{
+wchar_t *filename_w;
+int ret;
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+if (!filename_w)
+goto fallback;
+ret = _waccess(filename_w, par);
+av_free(filename_w);
+return ret;
+fallback:
+return _access(filename_utf8, par);
+}
+
+static inline void copy_stat(struct _stati64 *winstat, struct win32_stat *par)
+{
+par->st_dev   = winstat->st_dev;
+par->st_ino   = winstat->st_ino;
+par->st_mode  = winstat->st_mode;
+par->st_nlink = winstat->st_nlink;
+par->st_uid   = winstat->st_uid;
+par->st_gid   = winstat->st_gid;
+par->st_rdev  = winstat->st_rdev;
+par->st_size  = winstat->st_size;
+par->st_atime = winstat->st_atime;
+par->st_mtime = winstat->st_mtime;
+par->st_ctime = winstat->st_ctime;
 }
 
-DEF_FS_FUNCTION2(access, _waccess, _access, int)
-DEF_FS_FUNCTION2(stat, _wstati64, _stati64, struct stat*)
+static inline int win32_stat(const char *filename_utf8, struct win32_stat *par)
+{
+struct _stati64 winstat = { 0 };
+wchar_t *filename_w;
+int ret;
+
+if (get_extended_win32_path(filename_utf8, &filename_w))
+return -1;
+
+if (filename_w) {
+ret = _wstat64(filename_w, &winstat);
+av_free(filename_w);
+} else
+ret = _stat64(filename_utf8, &winstat);
+
+copy_stat(&winstat, par);
+
+return ret;
+}
+
+static inline int win32_fstat(int fd, struct win32_stat *par)
+{
+struct _stati64 winstat = { 0 };
+int ret;
+
+ret = _fstat64(fd, &winstat);
+
+copy_stat(&winstat, par);
+
+return ret;
+}
 
 static inline int win32_rename(const char *src_utf8, const char *dest_utf8)
 {
 wchar_t *src_w, *dest_w;
 int ret;
 
-if (utf8towchar(src

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

[softworkz]

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/libavformat/file.c
@@ -154,11 +154,7 @@ static int file_check(URLContext *h, int mask)
 ret |= AVIO_FLAG_WRITE;
 #else
 struct stat st;
-#   ifndef _WIN32
 ret = stat(filename, &st);
-#   else
-ret = win32_stat(filename, &st);
-#   endif
 if (ret < 0)
 return AVERROR(errno);
 
-- 
ffmpeg-codebot
___
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] Update ReadMe.md for PR submission and reference Developer Documentation

[Soft Works]

> -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 
> ---
> Update ReadMe.md for PR submission and reference Developer
> Documentation
> 
> .
> 
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-22%2Fsoftworkz%2Fpatch-2-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 22/softworkz/patch-2-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/22
> 
>  README.md | 18 --
>  1 file changed, 16 insertions(+), 2 deletions(-)
> 
> diff --git a/README.md b/README.md
> index f8c23f2870..07f717a4f9 100644
> --- a/README.md
> +++ b/README.md
> @@ -41,6 +41,20 @@ GPL. Please refer to the LICENSE file for detailed
> information.
> 
>  ## Contributing
> 
> +### Mailing List
> +
>  Patches should be submitted to the ffmpeg-devel mailing list using
> -`git format-patch` or `git send-email`. Github pull requests should be
> -avoided because they are not part of our review process and will be
> ignored.
> +`git format-patch` or `git send-email` as described in the
> +[Developer
> Documentation](https://www.ffmpeg.org/developer.html#Contributing).
> +
> +### Pull Requests
> +
> +There is a new experimental way that allows submitting Pull Requests
> +and having them forwarded to the ffmpeg Mailing List.
> +
> +Please submit your Pull Requests here:
> **https://github.com/ffstaging/FFmpeg**.
> +
> +Then, follow the instructions from the automatic CodeBot response.
> +Besides the submission procedure, the
> +[Developer
> Documentation](https://www.ffmpeg.org/developer.html#Contributing)
> +applies in the same way like when submitting to the ML directly.
> 
> base-commit: e1a14479a81f5366b95df543992a7fe637cf2dde
> --
> ffmpeg-codebot


Does anybody have objections regarding this doc change?

Thanks,
sw
___
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] avcodec/libaomenc: Add unmet target level warning

[James Zern]

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 applies basically the same approach used for libvpx.
> >
> > Signed-off-by: Bohan Li 
> > ---
> >  libavcodec/libaomenc.c | 64 ++
> >  1 file changed, 64 insertions(+)
> >
>
> lgtm.

> +} else if (target_levels[i] < 31) {
> +// Log the encoded level if a target level was given
> +av_log(avctx, AV_LOG_INFO,
> +   "Output level for operating point %d is %d.%d.",
> +   i, 2 + (levels[i] >> 2), levels[i] & 3);
> +}

Actually this is a bit spammy. If there's only one operating point set
then I'd expect a single line output, but this seems to print all 32
regardless. Is that expected?
___
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] libavfi/dnn: add LibTorch as one of DNN backend

[Fu, Ting]

> -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
> 
> 
> 
> > -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 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 one of FFmpeg DNN backend, would help the PyTorch users a
> lot.
> >
> > PS, ONNX is not in my plan. I am going to improve the LibTorch backend
> > performance and make it compatible with more models in next steps.
> >
> > Thank you.
> > Ting FU
> 
> Hi Ting,
> 
> I've never looked at the DNN part in ffmpeg, so just out of curiosity:
> 
> Is this working 1-way or 2-way? What I mean is whether this is just about
> feeding images to the AI engines or does the ffmpeg filter get some data in
> return for each frame that is processed?

Hi Softworkz,

Since the DNN is a part of FFmpeg libavfilter, so it can work with other 
filters. Other filters can get the output(metadata or just frames) from DNN.

> 
> So for example, in case of object identification/tracking, is it possible to 
> get
> identified rectangles back from the inference result, attach it to an AVFrame
> so that a downstream filter could paint those rectangles on each video frame?
> 

Yes, for your example object identification, we preserved the output in 
structure AVFrameSideData of AVFrame. So, the following filters can use such 
data.
And for now, the AVFrameSideData we saved contains bounding box, the object 
position info, and the object category and confidence.

Thank you.
Ting FU

> Thanks,
> softworkz
> 
> 
> 
> ___
> 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 2/2] libavfi/dnn: add LibTorch as one of DNN backend

[Fu, Ting]

> -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 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.
> Those are not to support different hardware, but different tastes for users,

Hi Jean-Baptiste,

Yes, you are right, we already got three backends with FFmpeg DNN. But for now, 
the native backend is barely workable, due to its layers and operations weak 
support.
And we do support different hardware. Like, the OpenVINO backend supports 
inference with Intel GPU. For now, the TensorFlow and OpenVINO backend support 
some models, which include Super Resolution model, object detect model, object 
classify model. I think it's not only a teste difference for users, but an 
option for them to choose for their work implementation. AFAIK, there are some 
individuals and organizations who are using FFmpeg DNN.

> who prefer one API to another one.
> Where does it end? How many of those backends will we get? 10?
> 
> What's the value to do that development inside ffmpeg?
> 

I think you are concerning why we need such backend. Because the users want to 
infer the BasicVSR and other VSR(video super solution) model. Those models are 
most implemented with PyTorch. And it can cause several issues if we convert 
such model to the other AI model file. Besides, the video codec is an advantage 
of FFmpeg framework, which can support various of hardware acceleration. We 
would like to utilize this framework to enhance the performance of AI inference 
and improve the user experience.
What I want to emphasis is that the LibTorch backend is not for adding patches 
but an actual requirement.

Thank you.
Ting FU

> --
> Jean-Baptiste Kempf -  President
> +33 672 704 734
> ___
> 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 v5] avcodec/mfenc: Dynamically load MFPlat.DLL

[Trystan Mata]

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 when you probably could just call 
LoadLibrary
 > directly. (There's no need for using wchar APIs and long path 
handling and

 > all that, when it's just given the hardcoded path "mfplat.dll".)

Ok, I will switch totally only LoadLibrary calls.

 > Secondly, this won't probably work as intended if you have two mfenc
 > instances running at the same time - you'd load the library twice 
but only

 > unload it once. To work around that, you can either add some sort of
 > reference counting around the library, or keep the library reference 
in a

 > per-encoder struct.
 >
 > In this case I think I would prefer to keep it in a struct.

 > This is called once per frame at least, right? For such cases I think it
 > would be much better if we'd keep the function pointer in a struct 
(which
 > then would be owned/contained in MFContext) so we don't need to look 
it up

 > every time.

I completely missed this. I'm not used to dynamic loading.
I will fix this by putting back the library handle and function ptrs in the
MFContext struct.

I think I will put each looked up symbol in the struct. So every MF 
function is loaded the same way.


 > This feels a bit messy with the same function defined differently 
between

 > the desktop/UWP cases. Wouldn't it be more straightforward to just keep
 > all the code for the desktop case, and add ifdefs within e.g.
 > ff_mf_load_library and ff_mf_unload_library, so that those functions are
 > simple no-ops if building for UWP?

I will fix that, thank you again for review.

// Trystan
___
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 v5] avcodec/mfenc: Dynamically load MFPlat.DLL

[Trystan Mata]

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 when you probably could just call 
LoadLibrary
> directly. (There's no need for using wchar APIs and long path 
handling and

> all that, when it's just given the hardcoded path "mfplat.dll".)

Ok, I will switch totally only LoadLibrary calls.

> Secondly, this won't probably work as intended if you have two mfenc
> instances running at the same time - you'd load the library twice but 
only

> unload it once. To work around that, you can either add some sort of
> reference counting around the library, or keep the library reference 
in a

> per-encoder struct.
>
> In this case I think I would prefer to keep it in a struct.

> This is called once per frame at least, right? For such cases I think it
> would be much better if we'd keep the function pointer in a struct 
(which
> then would be owned/contained in MFContext) so we don't need to look 
it up

> every time.

I completely missed this. I'm not used to dynamic loading.
I will fix this by putting back the library handle and function ptrs in the
MFContext struct.

I think I will put each looked up symbol in the struct. So every MF 
function is loaded the same way.


> This feels a bit messy with the same function defined differently 
between

> the desktop/UWP cases. Wouldn't it be more straightforward to just keep
> all the code for the desktop case, and add ifdefs within e.g.
> ff_mf_load_library and ff_mf_unload_library, so that those functions are
> simple no-ops if building for UWP?

I will fix that, thank you again for review.

// Trystan

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