[FFmpeg-devel] [PATCH 1/2] fate/filter-video: Remove unnecessary dependency from filter-pp[1-6]
filter-pp and filter-pp7 are the only ones of the filter-pp* tests that use the file generated by fate-vsynth1-mpeg4-qprd. Also combine the dependency on this test for all the tests that need it. Signed-off-by: Andreas Rheinhardt --- tests/fate/filter-video.mak | 7 +++ 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 7851d35db2..86408dd58c 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -583,7 +583,9 @@ fate-filter-pad: CMD = video_filter "pad=iw*1.5:ih*1.5:iw*0.3:ih*0.2" FATE_FILTER_PP = fate-filter-pp fate-filter-pp1 fate-filter-pp2 fate-filter-pp3 fate-filter-pp4 fate-filter-pp5 fate-filter-pp6 FATE_FILTER_VSYNTH-$(CONFIG_PP_FILTER) += $(FATE_FILTER_PP) -$(FATE_FILTER_PP): fate-vsynth1-mpeg4-qprd + +FATE_FILTER_VSYNTH1_MPEG4_QPRD := $(addprefix fate-filter-, pp pp7 spp codecview) +$(FATE_FILTER_VSYNTH1_MPEG4_QPRD): fate-vsynth1-mpeg4-qprd fate-vsynth1-mpeg4-qprd: KEEP_FILES ?= 1 fate-filter-pp: CMD = framecrc -flags bitexact -export_side_data venc_params -idct simple -i $(TARGET_PATH)/tests/data/fate/vsynth1-mpeg4-qprd.avi -frames:v 5 -flags +bitexact -vf "pp=be/hb/vb/tn/l5/al" @@ -595,15 +597,12 @@ fate-filter-pp5: CMD = video_filter "pp=md" fate-filter-pp6: CMD = video_filter "pp=be/fd" FATE_FILTER_VSYNTH-$(CONFIG_PP7_FILTER) += fate-filter-pp7 -fate-filter-pp7: fate-vsynth1-mpeg4-qprd fate-filter-pp7: CMD = framecrc -flags bitexact -export_side_data venc_params -idct simple -i $(TARGET_PATH)/tests/data/fate/vsynth1-mpeg4-qprd.avi -frames:v 5 -flags +bitexact -vf "pp7" FATE_FILTER_VSYNTH-$(CONFIG_SPP_FILTER) += fate-filter-spp -fate-filter-spp: fate-vsynth1-mpeg4-qprd fate-filter-spp: CMD = framecrc -flags bitexact -export_side_data venc_params -idct simple -i $(TARGET_PATH)/tests/data/fate/vsynth1-mpeg4-qprd.avi -frames:v 5 -flags +bitexact -vf "spp=idct=simple:dct=int" FATE_FILTER_VSYNTH-$(CONFIG_CODECVIEW_FILTER) += fate-filter-codecview -fate-filter-codecview: fate-vsynth1-mpeg4-qprd fate-filter-codecview: CMD = framecrc -flags bitexact -idct simple -flags2 +export_mvs -i $(TARGET_PATH)/tests/data/fate/vsynth1-mpeg4-qprd.avi -frames:v 5 -flags +bitexact -vf codecview=mv=pf+bf+bb FATE_FILTER_VSYNTH-$(call ALLYES, QP_FILTER PP_FILTER) += fate-filter-qp -- 2.32.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] tests/fate-run: Make AVCONV-tests honour -thread_type
Signed-off-by: Andreas Rheinhardt
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index c0d65be6f4..7e3457b3ba 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -195,7 +195,7 @@ enc_dec_pcm(){
}
FLAGS="-flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact"
-DEC_OPTS="-threads $threads -idct simple $FLAGS"
+DEC_OPTS="-threads $threads -thread_type $thread_type -idct simple $FLAGS"
ENC_OPTS="-threads 1-idct simple -dct fastint"
enc_dec(){
--
2.32.0
___
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] lib*/version: Move library version functions into files of their own
This avoids having to rebuild big files every time FFMPEG_VERSION
changes (which it does with every commit).
Signed-off-by: Andreas Rheinhardt
---
Makefile | 4 ++-
ffbuild/common.mak | 2 --
libavcodec/Makefile| 1 +
libavcodec/avcodec.c | 25 --
libavcodec/version.c | 50 +++
libavdevice/Makefile | 1 +
libavdevice/avdevice.c | 24 -
libavdevice/version.c | 45
libavfilter/Makefile | 1 +
libavfilter/avfilter.c | 23
libavfilter/version.c | 44 +++
libavformat/Makefile | 1 +
libavformat/utils.c| 21 ---
libavformat/version.c | 45
libavutil/Makefile | 1 +
libavutil/utils.c | 43 ---
libavutil/version.c| 71 ++
libpostproc/Makefile | 3 +-
libpostproc/postprocess.c | 21 ---
libpostproc/version.c | 44 +++
libswresample/Makefile | 1 +
libswresample/swresample.c | 21 ---
libswresample/version.c| 45
libswscale/Makefile| 1 +
libswscale/utils.c | 20 ---
libswscale/version.c | 41 ++
26 files changed, 397 insertions(+), 202 deletions(-)
create mode 100644 libavcodec/version.c
create mode 100644 libavdevice/version.c
create mode 100644 libavfilter/version.c
create mode 100644 libavformat/version.c
create mode 100644 libavutil/version.c
create mode 100644 libpostproc/version.c
create mode 100644 libswresample/version.c
create mode 100644 libswscale/version.c
diff --git a/Makefile b/Makefile
index 48cfb6e240..f38b521765 100644
--- a/Makefile
+++ b/Makefile
@@ -19,6 +19,8 @@ vpath %/fate_config.sh.template $(SRC_PATH)
TESTTOOLS = audiogen videogen rotozoom tiny_psnr tiny_ssim base64 audiomatch
HOSTPROGS := $(TESTTOOLS:%=tests/%) doc/print_options
+ALLFFLIBS = avcodec avdevice avfilter avformat avutil postproc swscale
swresample
+
# $(FFLIBS-yes) needs to be in linking order
FFLIBS-$(CONFIG_AVDEVICE) += avdevice
FFLIBS-$(CONFIG_AVFILTER) += avfilter
@@ -113,7 +115,7 @@ include $(SRC_PATH)/fftools/Makefile
include $(SRC_PATH)/doc/Makefile
include $(SRC_PATH)/doc/examples/Makefile
-libavcodec/avcodec.o libavformat/utils.o libavdevice/avdevice.o
libavfilter/avfilter.o libavutil/utils.o libpostproc/postprocess.o
libswresample/swresample.o libswscale/utils.o : libavutil/ffversion.h
+$(ALLFFLIBS:%=lib%/version.o): libavutil/ffversion.h
$(PROGS): %$(PROGSSUF)$(EXESUF): %$(PROGSSUF)_g$(EXESUF)
ifeq ($(STRIPTYPE),direct)
diff --git a/ffbuild/common.mak b/ffbuild/common.mak
index 42f7b23641..24113c59eb 100644
--- a/ffbuild/common.mak
+++ b/ffbuild/common.mak
@@ -29,8 +29,6 @@ $(foreach VAR,$(SILENT),$(eval override $(VAR) = @$($(VAR
$(eval INSTALL = @$(call ECHO,INSTALL,$$(^:$(SRC_DIR)/%=%)); $(INSTALL))
endif
-ALLFFLIBS = avcodec avdevice avfilter avformat avutil postproc swscale
swresample
-
# NASM requires -I path terminated with /
IFLAGS := -I. -I$(SRC_LINK)/
CPPFLAGS := $(IFLAGS) $(CPPFLAGS)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cfaa6f196a..1b60e0e1d4 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -56,6 +56,7 @@ OBJS = ac3_parser.o
\
qsv_api.o\
raw.o\
utils.o \
+ version.o\
vlc.o\
vorbis_parser.o \
xiph.o \
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index d11f035481..8afb6cd62e 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -40,31 +40,6 @@
#include "frame_thread_encoder.h"
#include "internal.h"
#include "thread.h"
-#include "version.h"
-
-#include "libavutil/ffversion.h"
-const char av_codec_ffversion[] = "FFmpeg version " FFMPEG_VERSION;
-
-unsigned avcodec_version(void)
-{
-av_assert0(AV_CODEC_ID_PCM_S8_PLANAR==65563);
-av_assert0(AV_CODEC_ID_ADPCM_G722==69660);
-av_assert0(AV_CODEC_ID_SRT==94216);
-av_assert0(LIBAVCODEC_VERSION_MICRO >= 100);
-
-return LIBAVCODEC_VERSION_INT;
-}
-
-const char *avcodec_configuration(void)
-{
-return FFMPEG_CONFIGURATION;
-}
-
-const char *avcodec_license(void)
-{
-#define LICENSE_PREFIX "libavcodec license: "
-return &LICENSE_PREFIX FFMPEG_LICENSE[sizeof(LICENSE_PREFIX) - 1];
-}
int avcodec_default_execute(AVCodecContext *c, int (*func)(AVCodecContext *c2,
void *arg2), void *arg, i
Re: [FFmpeg-devel] [PATCH] lib*/version: Move library version functions into files of their own
On Fri, 6 May 2022, Andreas Rheinhardt wrote: This avoids having to rebuild big files every time FFMPEG_VERSION changes (which it does with every commit). Signed-off-by: Andreas Rheinhardt --- Makefile | 4 ++- ffbuild/common.mak | 2 -- libavcodec/Makefile| 1 + libavcodec/avcodec.c | 25 -- libavcodec/version.c | 50 +++ libavdevice/Makefile | 1 + libavdevice/avdevice.c | 24 - libavdevice/version.c | 45 libavfilter/Makefile | 1 + libavfilter/avfilter.c | 23 libavfilter/version.c | 44 +++ libavformat/Makefile | 1 + libavformat/utils.c| 21 --- libavformat/version.c | 45 libavutil/Makefile | 1 + libavutil/utils.c | 43 --- libavutil/version.c| 71 ++ libpostproc/Makefile | 3 +- libpostproc/postprocess.c | 21 --- libpostproc/version.c | 44 +++ libswresample/Makefile | 1 + libswresample/swresample.c | 21 --- libswresample/version.c| 45 libswscale/Makefile| 1 + libswscale/utils.c | 20 --- libswscale/version.c | 41 ++ 26 files changed, 397 insertions(+), 202 deletions(-) LGTM, 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 v2] avformat/avio: use av_match_name to match protocol whitelist
On 4/29/22 12:01, Leo Izen wrote: This swaps av_match_list to av_match_name inside ffurl_connect, which allows ALL to be treated as a valid value on the whitelist in accordance with the behavior described in the documentation. --- Could someone please take a quick look at this? Thanks, - 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] lavu/common: fix PUT_UTF8() length
Ensure the input is <= 31 bits because otherwise it would produce
very invalid UTF-8.
Document that the length can be up to 6 bytes, because that is what
the code does. The FLAC encoder abuses UTF-8 to store 32-bits
integers, limiting PUT_UTF8() to 21 bits might affect some real
cases negatively.
Signed-off-by: Nicolas George
---
libavutil/common.h | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavutil/common.h b/libavutil/common.h
index fd1404be6c..7a71be3c81 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -505,7 +505,9 @@ static av_always_inline av_const int av_parity_c(uint32_t v)
/**
* @def PUT_UTF8(val, tmp, PUT_BYTE)
- * Convert a 32-bit Unicode character to its UTF-8 encoded form (up to 4 bytes
long).
+ * Convert a 32-bit Unicode character to its UTF-8 encoded form (up to 6
+ * bytes long, but codes more than 4 bytes long, i.e. codepoints above
+ * 0x001F, are deprecated).
* @param val is an input-only argument and should be of type uint32_t. It
holds
* a UCS-4 encoded Unicode character that is to be converted to UTF-8. If
* val is given as a function it is executed only once.
@@ -522,7 +524,7 @@ static av_always_inline av_const int av_parity_c(uint32_t v)
#define PUT_UTF8(val, tmp, PUT_BYTE)\
{\
int bytes, shift;\
-uint32_t in = val;\
+uint32_t in = val & 0x7FFF;\
if (in < 0x80) {\
tmp = in;\
PUT_BYTE\
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [WIP] [PATCH] libavutil: add a limited XML parser
Signed-off-by: Nicolas George
---
libavutil/Makefile | 3 +
libavutil/tests/xmlparser.c | 93 ++
libavutil/xmlparser.c | 644
libavutil/xmlparser.h | 58
4 files changed, 798 insertions(+)
create mode 100644 libavutil/tests/xmlparser.c
create mode 100644 libavutil/xmlparser.c
create mode 100644 libavutil/xmlparser.h
I promised this quite some time ago, I finally got around to work
through the first block and make something. It is still
work-in-progress, but I will have less time to work on it on the next
weeks, so I might as well put it out there.
Currently, it can parse into events a XML file without declarations or
comments. The goal is to make it enough to parse the files we actually
encounter in the field of multimedia, so that FFmpeg can do its work
without libxml2.
TODO:
- byte order mark
-
- comments
- doctype declaration
- check matching begin/end tags
- freeing memory
- buffer compaction
- extensive testing
- use it in FFmpeg
If there are XML files you want me to make sure the parser can digest,
please send them to me.
If there are features you want me to make sure are possible, please let
me know.
If there are FFmpeg components that you want me to port to using this
API, please tell me precisely how I can test them. The real case I
intend to implement first is matroskachapters.dtd.
I thin libavutil also needs a XML writer. And a JSON writer. Possibly
others. I want to work on it. But I refuse to do it unless we have a
good API to return the result: always returning mallocated buffers or a
similar obvious solution is wasteful and ugly. So please reply to this:
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-December/290226.html
Regards,
--
Nicolas George
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 81df3b0640..7dcf308e4a 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -84,6 +84,7 @@ HEADERS = adler32.h
\
twofish.h \
version.h \
video_enc_params.h\
+ xmlparser.h \
xtea.h\
tea.h \
tx.h \
@@ -168,6 +169,7 @@ OBJS = adler32.o
\
twofish.o\
utils.o \
xga_font_data.o \
+ xmlparser.o \
xtea.o \
tea.o\
tx.o \
@@ -258,6 +260,7 @@ TESTPROGS = adler32
\
tree\
twofish \
utf8\
+xmlparser \
xtea\
tea \
diff --git a/libavutil/tests/xmlparser.c b/libavutil/tests/xmlparser.c
new file mode 100644
index 00..f6823b4074
--- /dev/null
+++ b/libavutil/tests/xmlparser.c
@@ -0,0 +1,93 @@
+/*
+ * Copyright (c) 2022 Nicolas George
+ *
+ * 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
+#include
+
+#include "libavutil/error.h"
+#include "libavutil/xmlparser.h"
+
+static void dump_text(const uint8_t *text, size_t len)
+{
+size_t i;
+
+for (i = 0; i < len; i++)
+printf(text[i] < 32 ? "\\x%02x" : "%c", text[i]);
+}
+
+int main(int argc,
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> > As a matter of fact, you are. Your alternative method implies > > ploughing > > through hundreds of C files normalising path handling across the > > entire application, > Almost everybody here knows that this isn't true. I do not. During the review of just this particular patchset it was found that FFmpeg sometimes uses av_fopen_utf8 and sometimes just plain fopen. Plain fopens were already replaced with av_fopen_utf8 and then reverted back. because suddenly it turned out that av_fopen_utf8 is problematic: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295488.html. At least in one place backward slashes are being replaced with forward slashes, which is not compatible with \\?\. But you can easily prove me wrong by showing me your patches. As a starting point: it was already shown how LLVM prefixes paths https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295677.html. If that functionality is to be ported into FFmpeg, where exactly should the code go? Is there a Path struct, analogous to LLVM class, that all of FFmpeg is using? Or FFmpeg isn't using any special structs and paths are indistinguishable from ordinary strings? > Why should that be bad news for me? > Those are three very specific cases and we had already covered this. Because none of this is covered. They are covered by my patches, and you're against merging them. > My point is very simple: It should be a solution that will always > work and not just sometimes. Manifest works whether you like it or not. People without the registry setting do not have it for the simple reason of never having to work with long paths. And they most likely will enable it the first time such a need arises. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/jpeg2000: Fast fail if HTJ2K codeblocks are present.
LGTM
On Thu, May 5, 2022 at 11:56 PM caleb wrote:
>
> ---
> libavcodec/jpeg2000.h| 2 ++
> libavcodec/jpeg2000dec.c | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index d06313425e..e5ecb4cbf9 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -110,6 +110,8 @@ enum Jpeg2000Quantsty { // quantization style
> #define JPEG2000_CSTY_PREC 0x01 // Precincts defined in coding style
> #define JPEG2000_CSTY_SOP 0x02 // SOP marker present
> #define JPEG2000_CSTY_EPH 0x04 // EPH marker present
> +#define JPEG2000_CTSY_HTJ2K_F 0x40 // Only HT code-blocks (Rec. ITU-T
> T.814 | ISO/IEC 15444-15) are present
> +#define JPEG2000_CTSY_HTJ2K_M 0xC0 // HT code blocks (Rec. ITU-T T.814 |
> ISO/IEC 15444-15) can be present
>
> // Progression orders
> #define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
> level-component-position progression
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 92966b11f5..30f8c878d1 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -521,6 +521,10 @@ static int get_cox(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c)
>
> c->cblk_style = bytestream2_get_byteu(&s->g);
> if (c->cblk_style != 0) { // cblk style
> +if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
> JPEG2000_CTSY_HTJ2K_F) {
> +av_log(s->avctx, AV_LOG_ERROR, "Support for High throughput JPEG
> 2000 is not yet available\n");
> +return AVERROR_PATCHWELCOME;
> +}
> av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
> bypass\n");
> --
> 2.34.0
>
___
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 - libmad MP3 decoding support
5 May 2022, 01:47 by da...@megapico.co.uk: >> Andreas Rheinhardt wrote: >> >> David Fletcher: >> > Following today's posts about help with submitting patches I realised I >> > sent the libmad patch yesterday in the wrong format. Apologies, I was >> > not familiar with the git format patches. >> > >> > Hopefully the attached version is now in the correct format against the >> > current master branch. >> > >> > The bug report about why this exists is at the following link, including >> > a link to sample distorted audio from decoding an mp3 stream on ARMv4 >> > hardware: https://trac.ffmpeg.org/ticket/9764 >> > >> > Best regards, David. >> > >> I disagree with this patch. The native decoder should be fixed instead, or if it's not able to be fixed, users should use specialized libraries. We're not adding a yet another decoding library to fix an issue on very old ARM chips. I suspect the problem is with the MDCT. We already have a better and more precise fixed-point MDCT in libavutil/tx. The plan was to replace the MDCT in mp3 once lavu/tx has more assembly, but if it helps, should be fine to replace it now. ___ 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/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
On Fri, 2022-05-06 at 05:57 +, Tong Wu wrote:
> Fixes:
> $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
> -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
>
> Signed-off-by: Tong Wu
> ---
> libavutil/hwcontext_qsv.c | 16 +---
> 1 file changed, 13 insertions(+), 3 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index b28dcffe2a..bf150c8553 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1281,12 +1281,22 @@ static int qsv_frames_derive_from(AVHWFramesContext
> *dst_ctx,
> #if CONFIG_D3D11VA
> case AV_HWDEVICE_TYPE_D3D11VA:
> {
> +D3D11_TEXTURE2D_DESC texDesc;
> +dst_ctx->initial_pool_size = src_ctx->initial_pool_size;
> AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> +dst_hwctx->texture_infos = av_calloc(src_hwctx->nb_surfaces,
> + sizeof(*dst_hwctx-
> >texture_infos));
Please check whether the pointer is NULL
> if (src_hwctx->frame_type & MFX_MEMTYPE_SHARED_RESOURCE)
> dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> -dst_hwctx->BindFlags = qsv_get_d3d11va_bind_flags(src_hwctx-
> >frame_type);
> +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> +mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> >surfaces[i].Data.MemId;
> +dst_hwctx->texture_infos[i].texture = (ID3D11Texture2D*)pair-
> >first;
> +dst_hwctx->texture_infos[i].index = pair->second ==
> (mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
> +if (i == 0) {
> +ID3D11Texture2D_GetDesc(dst_hwctx-
> >texture_infos[i].texture, &texDesc);
> +}
Move this out of the for-loop ? You may call ID3D11Texture2D_GetDesc() below:
ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture, &texDesc);
Thanks
Haihao
> +}
> +dst_hwctx->BindFlags = texDesc.BindFlags;
> }
> break;
> #endif
___
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/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Saturday, May 7, 2022 4:36 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wu, Tong1
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/3] avutil/hwcontext_qsv:
> derive QSV frames to D3D11VA frames
>
> On Fri, 2022-05-06 at 05:57 +, Tong Wu wrote:
> > Fixes:
> > $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> > -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
> > -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
> >
> > Signed-off-by: Tong Wu
> > ---
> > libavutil/hwcontext_qsv.c | 16 +---
> > 1 file changed, 13 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index b28dcffe2a..bf150c8553 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -1281,12 +1281,22 @@ static int
> qsv_frames_derive_from(AVHWFramesContext
> > *dst_ctx,
> > #if CONFIG_D3D11VA
> > case AV_HWDEVICE_TYPE_D3D11VA:
> > {
> > +D3D11_TEXTURE2D_DESC texDesc;
> > +dst_ctx->initial_pool_size = src_ctx-
> >initial_pool_size;
> > AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> > -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > >surfaces[i].Data.MemId;
> > -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> > +dst_hwctx->texture_infos = av_calloc(src_hwctx-
> >nb_surfaces,
> > + sizeof(*dst_hwctx-
> > >texture_infos));
>
> Please check whether the pointer is NULL
>
> > if (src_hwctx->frame_type &
> MFX_MEMTYPE_SHARED_RESOURCE)
> > dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> > -dst_hwctx->BindFlags =
> qsv_get_d3d11va_bind_flags(src_hwctx-
> > >frame_type);
> > +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> > +mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > >surfaces[i].Data.MemId;
> > +dst_hwctx->texture_infos[i].texture =
> (ID3D11Texture2D*)pair-
> > >first;
> > +dst_hwctx->texture_infos[i].index = pair->second ==
> > (mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
> > +if (i == 0) {
> > +ID3D11Texture2D_GetDesc(dst_hwctx-
> > >texture_infos[i].texture, &texDesc);
> > +}
>
> Move this out of the for-loop ? You may call ID3D11Texture2D_GetDesc()
> below:
>
> ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
> &texDesc);
This could crash when src_hwctx->nb_surfaces is 0
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 v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> -Original Message- > From: ffmpeg-devel On Behalf Of nil- > admir...@mailo.com > Sent: Friday, May 6, 2022 6:08 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v11 1/6] > libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and > utf8toansi > > > > As a matter of fact, you are. Your alternative method implies > > > ploughing > > > through hundreds of C files normalising path handling across the > > > entire application, > > > Almost everybody here knows that this isn't true. > > I do not. During the review of just this particular patchset it was > found that FFmpeg > sometimes uses av_fopen_utf8 and sometimes just plain fopen. Plain > fopens > were already replaced with av_fopen_utf8 and then reverted back. > because suddenly it turned out that av_fopen_utf8 is problematic: > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-April/295488.html. Read again. As each lib gets its own copy of file_open.c there's no problem using av_fopen_utf8. The concern in that message was about it being a public API that could be used by external callers. > At least in one place backward slashes are being replaced with forward > slashes, > which is not compatible with \\?\. That's the pending issue with your 4/6 which is probably ok otherwise. > > Why should that be bad news for me? > > Those are three very specific cases and we had already covered this. > > Because none of this is covered. They are covered by my patches, > and you're against merging them. 5/6 + 6/6 are the manifest changes 4/6 see above (forward slash replacement problem) 3/6 is pointless without 5/6 2/6 is pointless without 6/6 1/6 remaining bits can be inlined in 4/6 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] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows
> -Original Message- > From: ffmpeg-devel On Behalf Of > Martin Storsjö > Sent: Wednesday, April 20, 2022 2:48 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing > issue on Windows > > Hi, > > I just became aware of the av_fopen_utf8 function - which was > introduced > to fix path name translations on Windows - actually has a notable > design > flaw. Hi Martin, I just became aware that somebody would be compiling ffmpeg like this on Windows and I'm curious regarding the whereabouts.. > Background: > > On Windows, a process can contain more than one C runtime (CRT); the > system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC > builds, each DLL/EXE can have one statically linked in instead of > linking > against a shared library CRT (and that's actually the default > configuration when building with MSVC). The default configuration for both, EXE and DLL projects is to link to the C runtime dynamically (crt dll). > This means that CRT objects (file descriptors from open(), FILE* > opened > with fopen/fdopen) mustn't be shared across DLLs; such an object must > be > opened, accessed and closed within the same DLL. This only happens when you explicitly modify the build configuration to statically link to the CRT. It is generally discouraged to mix (or have multiple) CRTs in a single process, but it's surely valid and there can be very good reasons to do so. Yet, such reasons are typically about achieving a certain level of independence between libraries and their dependencies and interdependencies. What's probably a bit more unusual is to build libraries like the ffmpeg libs which are very closely related and dependent in a way that each of them has its own static copy of the CRT compiled into it. I'm curious about two things: Why are you compiling it this way? Your earlier patch is from 2013, so you seem to be doing so for quite a while. Is the file API the only case where you had any trouble? I don't have experience with that kind of setup, but I would have thought that with separate CRTs, you could already get into trouble when you would allocate a string in the main application which you pass to any of the DLL's APIs and which might get freed by the DLL at a later time - doesn't that fail? 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] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows
Soft Works: > > >> -Original Message- >> From: ffmpeg-devel On Behalf Of >> Martin Storsjö >> Sent: Wednesday, April 20, 2022 2:48 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object sharing >> issue on Windows >> >> Hi, >> >> I just became aware of the av_fopen_utf8 function - which was >> introduced >> to fix path name translations on Windows - actually has a notable >> design >> flaw. > > Hi Martin, > > I just became aware that somebody would be compiling ffmpeg like > this on Windows and I'm curious regarding the whereabouts.. > >> Background: >> >> On Windows, a process can contain more than one C runtime (CRT); the >> system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC >> builds, each DLL/EXE can have one statically linked in instead of >> linking >> against a shared library CRT (and that's actually the default >> configuration when building with MSVC). > > The default configuration for both, EXE and DLL projects is to link > to the C runtime dynamically (crt dll). > >> This means that CRT objects (file descriptors from open(), FILE* >> opened >> with fopen/fdopen) mustn't be shared across DLLs; such an object must >> be >> opened, accessed and closed within the same DLL. > > This only happens when you explicitly modify the build configuration > to statically link to the CRT. > It is generally discouraged to mix (or have multiple) CRTs in a single > process, but it's surely valid and there can be very good reasons to > do so. Yet, such reasons are typically about achieving a certain level > of independence between libraries and their dependencies and > interdependencies. > What's probably a bit more unusual is to build libraries like the > ffmpeg libs which are very closely related and dependent in a way > that each of them has its own static copy of the CRT compiled into it. > > I'm curious about two things: > > Why are you compiling it this way? > Your earlier patch is from 2013, so you seem to be doing so for > quite a while. > > > Is the file API the only case where you had any trouble? > > I don't have experience with that kind of setup, but I would have > thought that with separate CRTs, you could already get into trouble > when you would allocate a string in the main application which > you pass to any of the DLL's APIs and which might get freed by > the DLL at a later time - doesn't that fail? > Whenever any of the FFmpeg libraries takes ownership of a string or another buffer*, we require it to be freeable with av_free (typically by saying that it needs to be allocated with the av_malloc family of functions). So all allocs and frees have to happen in libavutil. This is also true for all the other allocations directly performed by the the FFmpeg libraries. (The only exceptions to this are AVBuffer(Ref)s which allow users to use custom allocators and destructors.) - 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] av_fopen_utf8 and cross-DLL CRT object sharing issue on Windows
> -Original Message- > From: ffmpeg-devel On Behalf Of > Andreas Rheinhardt > Sent: Saturday, May 7, 2022 6:32 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object > sharing issue on Windows > > Soft Works: > > > > > >> -Original Message- > >> From: ffmpeg-devel On Behalf Of > >> Martin Storsjö > >> Sent: Wednesday, April 20, 2022 2:48 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: [FFmpeg-devel] av_fopen_utf8 and cross-DLL CRT object > sharing > >> issue on Windows > >> > >> Hi, > >> > >> I just became aware of the av_fopen_utf8 function - which was > >> introduced > >> to fix path name translations on Windows - actually has a notable > >> design > >> flaw. > > > > Hi Martin, > > > > I just became aware that somebody would be compiling ffmpeg like > > this on Windows and I'm curious regarding the whereabouts.. > > > >> Background: > >> > >> On Windows, a process can contain more than one C runtime (CRT); > the > >> system comes with two shared ones (UCRT and msvcrt.dll) and in MSVC > >> builds, each DLL/EXE can have one statically linked in instead of > >> linking > >> against a shared library CRT (and that's actually the default > >> configuration when building with MSVC). > > > > The default configuration for both, EXE and DLL projects is to link > > to the C runtime dynamically (crt dll). > > > >> This means that CRT objects (file descriptors from open(), FILE* > >> opened > >> with fopen/fdopen) mustn't be shared across DLLs; such an object > must > >> be > >> opened, accessed and closed within the same DLL. > > > > This only happens when you explicitly modify the build configuration > > to statically link to the CRT. > > It is generally discouraged to mix (or have multiple) CRTs in a > single > > process, but it's surely valid and there can be very good reasons to > > do so. Yet, such reasons are typically about achieving a certain > level > > of independence between libraries and their dependencies and > > interdependencies. > > What's probably a bit more unusual is to build libraries like the > > ffmpeg libs which are very closely related and dependent in a way > > that each of them has its own static copy of the CRT compiled into > it. > > > > I'm curious about two things: > > > > Why are you compiling it this way? > > Your earlier patch is from 2013, so you seem to be doing so for > > quite a while. > > > > > > Is the file API the only case where you had any trouble? > > > > I don't have experience with that kind of setup, but I would have > > thought that with separate CRTs, you could already get into trouble > > when you would allocate a string in the main application which > > you pass to any of the DLL's APIs and which might get freed by > > the DLL at a later time - doesn't that fail? > > > > Whenever any of the FFmpeg libraries takes ownership of a string or > another buffer*, we require it to be freeable with av_free (typically > by > saying that it needs to be allocated with the av_malloc family of > functions). So all allocs and frees have to happen in libavutil. This > is > also true for all the other allocations directly performed by the the > FFmpeg libraries. > (The only exceptions to this are AVBuffer(Ref)s which allow users to > use > custom allocators and destructors.) Ah yes of course, thanks for the explanation. I still wonder whether there aren't any other issues when multiple CRTs are being used? Or are the file IO APIs the only "weak" point with regards to multiple CRTs being used? 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 v4 1/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
On Sat, 2022-05-07 at 02:42 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Xiang, Haihao
> > Sent: Saturday, May 7, 2022 4:36 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Wu, Tong1
> > Subject: Re: [FFmpeg-devel] [PATCH v4 1/3] avutil/hwcontext_qsv:
> > derive QSV frames to D3D11VA frames
> >
> > On Fri, 2022-05-06 at 05:57 +, Tong Wu wrote:
> > > Fixes:
> > > $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> > > -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
> > > -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
> > >
> > > Signed-off-by: Tong Wu
> > > ---
> > > libavutil/hwcontext_qsv.c | 16 +---
> > > 1 file changed, 13 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > > index b28dcffe2a..bf150c8553 100644
> > > --- a/libavutil/hwcontext_qsv.c
> > > +++ b/libavutil/hwcontext_qsv.c
> > > @@ -1281,12 +1281,22 @@ static int
> >
> > qsv_frames_derive_from(AVHWFramesContext
> > > *dst_ctx,
> > > #if CONFIG_D3D11VA
> > > case AV_HWDEVICE_TYPE_D3D11VA:
> > > {
> > > +D3D11_TEXTURE2D_DESC texDesc;
> > > +dst_ctx->initial_pool_size = src_ctx-
> > > initial_pool_size;
> > > AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> > > -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > surfaces[i].Data.MemId;
> > >
> > > -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> > > +dst_hwctx->texture_infos = av_calloc(src_hwctx-
> > > nb_surfaces,
> > > + sizeof(*dst_hwctx-
> > > > texture_infos));
> >
> > Please check whether the pointer is NULL
> >
> > > if (src_hwctx->frame_type &
> >
> > MFX_MEMTYPE_SHARED_RESOURCE)
> > > dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> > > -dst_hwctx->BindFlags =
> >
> > qsv_get_d3d11va_bind_flags(src_hwctx-
> > > > frame_type);
> > >
> > > +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> > > +mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > surfaces[i].Data.MemId;
> > >
> > > +dst_hwctx->texture_infos[i].texture =
> >
> > (ID3D11Texture2D*)pair-
> > > > first;
> > >
> > > +dst_hwctx->texture_infos[i].index = pair->second ==
> > > (mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
> > > +if (i == 0) {
> > > +ID3D11Texture2D_GetDesc(dst_hwctx-
> > > > texture_infos[i].texture, &texDesc);
> > >
> > > +}
> >
> > Move this out of the for-loop ? You may call ID3D11Texture2D_GetDesc()
> > below:
> >
> > ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
> > &texDesc);
>
> This could crash when src_hwctx->nb_surfaces is 0
src_hwctx->nb_surface should be greater than 0, see qsv_init_pool() and
qsv_frames_derive_to().
On the other hand, dst_hwctx->texture_infos is NULL if src_hwctx->nb_surfaces is
0. I commented that we should check whether the pointer is NULL. In addition,
texDesc.BindFlags would be uninitialized if src_hwctx->nb_surfaces is 0, so we
couldn't use it in the following assignment.
dst_hwctx->BindFlags = texDesc.BindFlags;
Thanks
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 v4 1/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Xiang, Haihao
> Sent: Saturday, May 7, 2022 7:25 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Wu, Tong1
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/3] avutil/hwcontext_qsv:
> derive QSV frames to D3D11VA frames
>
> On Sat, 2022-05-07 at 02:42 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Xiang, Haihao
> > > Sent: Saturday, May 7, 2022 4:36 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Wu, Tong1
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/3] avutil/hwcontext_qsv:
> > > derive QSV frames to D3D11VA frames
> > >
> > > On Fri, 2022-05-06 at 05:57 +, Tong Wu wrote:
> > > > Fixes:
> > > > $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> > > > -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
> > > > -vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
> > > >
> > > > Signed-off-by: Tong Wu
> > > > ---
> > > > libavutil/hwcontext_qsv.c | 16 +---
> > > > 1 file changed, 13 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavutil/hwcontext_qsv.c
> b/libavutil/hwcontext_qsv.c
> > > > index b28dcffe2a..bf150c8553 100644
> > > > --- a/libavutil/hwcontext_qsv.c
> > > > +++ b/libavutil/hwcontext_qsv.c
> > > > @@ -1281,12 +1281,22 @@ static int
> > >
> > > qsv_frames_derive_from(AVHWFramesContext
> > > > *dst_ctx,
> > > > #if CONFIG_D3D11VA
> > > > case AV_HWDEVICE_TYPE_D3D11VA:
> > > > {
> > > > +D3D11_TEXTURE2D_DESC texDesc;
> > > > +dst_ctx->initial_pool_size = src_ctx-
> > > > initial_pool_size;
> > > > AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> > > > -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > > surfaces[i].Data.MemId;
> > > >
> > > > -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> > > > +dst_hwctx->texture_infos = av_calloc(src_hwctx-
> > > > nb_surfaces,
> > > > +
> sizeof(*dst_hwctx-
> > > > > texture_infos));
> > >
> > > Please check whether the pointer is NULL
> > >
> > > > if (src_hwctx->frame_type &
> > >
> > > MFX_MEMTYPE_SHARED_RESOURCE)
> > > > dst_hwctx->MiscFlags =
> D3D11_RESOURCE_MISC_SHARED;
> > > > -dst_hwctx->BindFlags =
> > >
> > > qsv_get_d3d11va_bind_flags(src_hwctx-
> > > > > frame_type);
> > > >
> > > > +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> > > > +mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > > surfaces[i].Data.MemId;
> > > >
> > > > +dst_hwctx->texture_infos[i].texture =
> > >
> > > (ID3D11Texture2D*)pair-
> > > > > first;
> > > >
> > > > +dst_hwctx->texture_infos[i].index = pair-
> >second ==
> > > > (mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
> > > > +if (i == 0) {
> > > > +ID3D11Texture2D_GetDesc(dst_hwctx-
> > > > > texture_infos[i].texture, &texDesc);
> > > >
> > > > +}
> > >
> > > Move this out of the for-loop ? You may call
> ID3D11Texture2D_GetDesc()
> > > below:
> > >
> > > ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
> > > &texDesc);
> >
> > This could crash when src_hwctx->nb_surfaces is 0
>
> src_hwctx->nb_surface should be greater than 0, see qsv_init_pool()
> and
> qsv_frames_derive_to().
>
> On the other hand, dst_hwctx->texture_infos is NULL if src_hwctx-
> >nb_surfaces is
> 0. I commented that we should check whether the pointer is NULL. In
> addition,
> texDesc.BindFlags would be uninitialized if src_hwctx->nb_surfaces is
> 0, so we
> couldn't use it in the following assignment.
>
> dst_hwctx->BindFlags = texDesc.BindFlags;
Yea that’s right. That would have to go into the if block, but
you're right, the whole thing would fail if nb_surfaces is 0
rather it wouldn't even get that far that this function would be
called, so it really doesn't matter, yet the getdesc and the
BindFlags assignment should better be together (wherever).
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 v4 1/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> On Sat, 2022-05-07 at 02:42 +, Soft Works wrote:
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Xiang, Haihao
> > > Sent: Saturday, May 7, 2022 4:36 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Wu, Tong1
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 1/3] avutil/hwcontext_qsv:
> > > derive QSV frames to D3D11VA frames
> > >
> > > On Fri, 2022-05-06 at 05:57 +, Tong Wu wrote:
> > > > Fixes:
> > > > $ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
> > > > -init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \ -vf
> > > > "hwmap=derive_device=d3d11va,format=d3d11" -f null -
> > > >
> > > > Signed-off-by: Tong Wu
> > > > ---
> > > > libavutil/hwcontext_qsv.c | 16 +---
> > > > 1 file changed, 13 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > > > index b28dcffe2a..bf150c8553 100644
> > > > --- a/libavutil/hwcontext_qsv.c
> > > > +++ b/libavutil/hwcontext_qsv.c
> > > > @@ -1281,12 +1281,22 @@ static int
> > >
> > > qsv_frames_derive_from(AVHWFramesContext
> > > > *dst_ctx,
> > > > #if CONFIG_D3D11VA
> > > > case AV_HWDEVICE_TYPE_D3D11VA:
> > > > {
> > > > +D3D11_TEXTURE2D_DESC texDesc;
> > > > +dst_ctx->initial_pool_size = src_ctx-
> > > > initial_pool_size;
> > > > AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
> > > > -mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > > surfaces[i].Data.MemId;
> > > >
> > > > -dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
> > > > +dst_hwctx->texture_infos = av_calloc(src_hwctx-
> > > > nb_surfaces,
> > > > +
> > > > + sizeof(*dst_hwctx-
> > > > > texture_infos));
> > >
> > > Please check whether the pointer is NULL
> > >
> > > > if (src_hwctx->frame_type &
> > >
> > > MFX_MEMTYPE_SHARED_RESOURCE)
> > > > dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
> > > > -dst_hwctx->BindFlags =
> > >
> > > qsv_get_d3d11va_bind_flags(src_hwctx-
> > > > > frame_type);
> > > >
> > > > +for (i = 0; i < src_hwctx->nb_surfaces; i++) {
> > > > +mfxHDLPair *pair = (mfxHDLPair*)src_hwctx-
> > > > > surfaces[i].Data.MemId;
> > > >
> > > > +dst_hwctx->texture_infos[i].texture =
> > >
> > > (ID3D11Texture2D*)pair-
> > > > > first;
> > > >
> > > > +dst_hwctx->texture_infos[i].index = pair->second
> > > > + ==
> > > > (mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
> > > > +if (i == 0) {
> > > > +ID3D11Texture2D_GetDesc(dst_hwctx-
> > > > > texture_infos[i].texture, &texDesc);
> > > >
> > > > +}
> > >
> > > Move this out of the for-loop ? You may call
> > > ID3D11Texture2D_GetDesc()
> > > below:
> > >
> > > ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
> > > &texDesc);
> >
> > This could crash when src_hwctx->nb_surfaces is 0
>
> src_hwctx->nb_surface should be greater than 0, see qsv_init_pool() and
> qsv_frames_derive_to().
>
> On the other hand, dst_hwctx->texture_infos is NULL if src_hwctx-
> >nb_surfaces is 0. I commented that we should check whether the pointer is
> NULL. In addition, texDesc.BindFlags would be uninitialized if src_hwctx-
> >nb_surfaces is 0, so we couldn't use it in the following assignment.
>
> dst_hwctx->BindFlags = texDesc.BindFlags;
>
> Thanks
> Haihao
>
Yes that's right. I am going to modify the code as suggested and resubmit them.
Regards,
Tong
___
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/3] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
Fixes:
$ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
-init_hw_device qsv=qsv@d3d11 -c:v h264_qsv -i input.h264 \
-vf "hwmap=derive_device=d3d11va,format=d3d11" -f null -
Signed-off-by: Tong Wu
---
libavutil/hwcontext_qsv.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index b28dcffe2a..ca21543075 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1281,12 +1281,22 @@ static int qsv_frames_derive_from(AVHWFramesContext
*dst_ctx,
#if CONFIG_D3D11VA
case AV_HWDEVICE_TYPE_D3D11VA:
{
+D3D11_TEXTURE2D_DESC texDesc;
+dst_ctx->initial_pool_size = src_ctx->initial_pool_size;
AVD3D11VAFramesContext *dst_hwctx = dst_ctx->hwctx;
-mfxHDLPair *pair = (mfxHDLPair*)src_hwctx->surfaces[i].Data.MemId;
-dst_hwctx->texture = (ID3D11Texture2D*)pair->first;
+dst_hwctx->texture_infos = av_calloc(src_hwctx->nb_surfaces,
+
sizeof(*dst_hwctx->texture_infos));
+if (!dst_hwctx->texture_infos)
+return AVERROR(ENOMEM);
if (src_hwctx->frame_type & MFX_MEMTYPE_SHARED_RESOURCE)
dst_hwctx->MiscFlags = D3D11_RESOURCE_MISC_SHARED;
-dst_hwctx->BindFlags =
qsv_get_d3d11va_bind_flags(src_hwctx->frame_type);
+for (i = 0; i < src_hwctx->nb_surfaces; i++) {
+mfxHDLPair *pair =
(mfxHDLPair*)src_hwctx->surfaces[i].Data.MemId;
+dst_hwctx->texture_infos[i].texture =
(ID3D11Texture2D*)pair->first;
+dst_hwctx->texture_infos[i].index = pair->second ==
(mfxMemId)MFX_INFINITE ? (intptr_t)0 : (intptr_t)pair->second;
+}
+ID3D11Texture2D_GetDesc(dst_hwctx->texture_infos[0].texture,
&texDesc);
+dst_hwctx->BindFlags = texDesc.BindFlags;
}
break;
#endif
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5 2/3] avutil/hwcontext_d3d11va: pass the format value from outside for staging texture
In d3d11va_create_staging_texture(), during the hwmap process, the
ctx->internal->priv is not initialized, resulting in the
texDesc.Format not initialized. Now pass the format value from
d3d11va_transfer_data() to fix it.
$ ffmpeg.exe -y -hwaccel qsv -init_hw_device d3d11va=d3d11 \
-init_hw_device qsv=qsv@d3d11 -c:v h264_qsv \
-i input.h264 -vf
"hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" \
-f null -
Signed-off-by: Tong Wu
---
libavutil/hwcontext_d3d11va.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 2b4e24bb56..bb4e9d6965 100644
--- a/libavutil/hwcontext_d3d11va.c
+++ b/libavutil/hwcontext_d3d11va.c
@@ -346,7 +346,7 @@ static int d3d11va_transfer_get_formats(AVHWFramesContext
*ctx,
return 0;
}
-static int d3d11va_create_staging_texture(AVHWFramesContext *ctx)
+static int d3d11va_create_staging_texture(AVHWFramesContext *ctx, DXGI_FORMAT
format)
{
AVD3D11VADeviceContext *device_hwctx = ctx->device_ctx->hwctx;
D3D11VAFramesContext *s = ctx->internal->priv;
@@ -355,7 +355,7 @@ static int d3d11va_create_staging_texture(AVHWFramesContext
*ctx)
.Width = ctx->width,
.Height = ctx->height,
.MipLevels = 1,
-.Format = s->format,
+.Format = format,
.SampleDesc = { .Count = 1 },
.ArraySize = 1,
.Usage = D3D11_USAGE_STAGING,
@@ -411,7 +411,8 @@ static int d3d11va_transfer_data(AVHWFramesContext *ctx,
AVFrame *dst,
device_hwctx->lock(device_hwctx->lock_ctx);
if (!s->staging_texture) {
-int res = d3d11va_create_staging_texture(ctx);
+ID3D11Texture2D_GetDesc((ID3D11Texture2D *)texture, &desc);
+int res = d3d11va_create_staging_texture(ctx, desc.Format);
if (res < 0)
return res;
}
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5 3/3] avutil/hwcontext_qsv: fix mapping issue between QSV frames and D3D11VA frames
Fixes:
$ ffmpeg.exe -init_hw_device d3d11va=d3d11 -init_hw_device \
qsv=qsv@d3d11 -s:v WxH -pix_fmt nv12 -i input.yuv -vf \
"hwupload=extra_hw_frames=16,hwmap=derive_device=d3d11va,format=d3d11,\
hwmap=derive_device=qsv,format=qsv" -f null -
Signed-off-by: Tong Wu
---
libavutil/hwcontext_qsv.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index ca21543075..81b298dc20 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1387,7 +1387,7 @@ static int qsv_map_from(AVHWFramesContext *ctx,
if (child_frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
dst->data[0] = pair->first;
-dst->data[1] = pair->second;
+dst->data[1] = pair->second == (mfxMemId)MFX_INFINITE ? (uint8_t
*)0 : pair->second;
} else {
dst->data[3] = child_data;
}
@@ -1417,7 +1417,7 @@ static int qsv_map_from(AVHWFramesContext *ctx,
if (child_frames_ctx->device_ctx->type == AV_HWDEVICE_TYPE_D3D11VA) {
mfxHDLPair *pair = (mfxHDLPair*)surf->Data.MemId;
dummy->data[0] = pair->first;
-dummy->data[1] = pair->second;
+dummy->data[1] = pair->second == (mfxMemId)MFX_INFINITE ? (uint8_t *)0
: pair->second;
} else {
dummy->data[3] = child_data;
}
@@ -1884,7 +1884,8 @@ static int qsv_map_to(AVHWFramesContext *dst_ctx,
{
mfxHDLPair *pair = (mfxHDLPair*)hwctx->surfaces[i].Data.MemId;
if (pair->first == src->data[0]
-&& pair->second == src->data[1]) {
+&& (pair->second == src->data[1]
+|| (pair->second == (mfxMemId)MFX_INFINITE && src->data[1]
== (uint8_t *)0))) {
index = i;
break;
}
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/dhav: Don't truncate return value of avio_skip()
Fixes demuxing files bigger than INT_MAX.
Reported-by: jenster
Signed-off-by: Andreas Rheinhardt
---
This has just been reported by jenster on IRC:
I found a bug in libavformat/dhav.c where it fails to demux files >
INT_MAX. It's basically assigning the result of avio_skip (which returns an
int64_t file offset) to an int in two places which it then checks if it's less
than 0 and when the file is bigger than INT_MAX it overflows and becomes
negative and errors out (this seems like something
that static analysis should find). It's a two line fix (basically
just change two ints to int64_t) https://pastebin.com/iUGe9cza (licensed CC0).
Would anyone be able to submit this change or fix it their own way? I don't
care about credit and I really don't want to bother with the whole patch
submission process for this trivial change.
libavformat/dhav.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavformat/dhav.c b/libavformat/dhav.c
index 60aab8cabd..9d26efe8fc 100644
--- a/libavformat/dhav.c
+++ b/libavformat/dhav.c
@@ -78,10 +78,11 @@ static const uint32_t sample_rates[] = {
static int parse_ext(AVFormatContext *s, int length)
{
DHAVContext *dhav = s->priv_data;
-int index, ret = 0;
+int64_t ret = 0;
while (length > 0) {
int type = avio_r8(s->pb);
+int index;
switch (type) {
case 0x80:
@@ -168,8 +169,7 @@ static int read_chunk(AVFormatContext *s)
{
DHAVContext *dhav = s->priv_data;
int frame_length, ext_length;
-int64_t start, end;
-int ret;
+int64_t start, end, ret;
if (avio_feof(s->pb))
return AVERROR_EOF;
--
2.32.0
___
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".
