Re: [FFmpeg-devel] [PATCH v6 1/2] lavc/vaapi_encode: add support for maxframesize
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Saturday, April 30, 2022 10:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v6 1/2] lavc/vaapi_encode: add support for
> maxframesize
>
> On 29/04/2022 08:31, Fei Wang wrote:
> > From: Linjie Fu
> >
> > Add support for max frame size:
> > - max_frame_size (bytes) to indicate the max allowed size for frame.
> >
> > If the frame size exceeds the limitation, encoder will to control the
> > frame size by adjusting QP value.
> >
> > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
> > -v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
> > -c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
> > -bf 3 -max_frame_size 4 -vframes 100 -y
> > ./max_frame_size.h264
>
> Can you give some more explanation of the circumstances in which this is
> expected to work in?
>
> For example, I tried a simple test I gave the Intel (gen9, iHD) H.264 encoder
> white noise.
>
> At QP 51 I get:
>
> $ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -
> framerate 30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -
> vf hwupload -c:v h264_vaapi -g 0 -qp 51 -f null - 2>&1 | grep 'Output buffer:'
> [h264_vaapi @ 0x557de0809640] Output buffer: 190975 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191265 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191825 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191893 bytes (status
> 0133).
> [h264_vaapi @ 0x557de0809640] Output buffer: 191746 bytes (status
> 0133).
>
> So I should be able to set the max_frame_size to 20 (with a corresponding
> bitrate target of 30*20*8 = 48M) and it will respect that?
>
> $ ./ffmpeg_g -v 55 -y -f rawvideo -video_size 1280x720 -pixel_format nv12 -
> framerate 30 -i /dev/urandom -an -init_hw_device vaapi:/dev/dri/renderD128 -
> vf hwupload -c:v h264_vaapi -g 0 -b:v 48M -max_frame_size 20 -f null -
> 2>&1 | grep 'Output buffer:'
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 204360 bytes (status 0433).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 201899 bytes (status 0433).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 194869 bytes (status 0233).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 191128 bytes (status 0133).
> [h264_vaapi @ 0x5566f49b7580] Output buffer: 191348 bytes (status 0133).
>
> But it still has some convergence delay, which really isn't what I expect
> from an
> absolute option like max_frame_size.
>
> (The 0400 in 0433 is
> VA_CODED_BUF_STATUS_NUMBER_PASSES_MASK (0xf00), indicating that
> it took four (!) passes across the frame and still didn't achieve the target
> we
> know is possible from the previous test.)
>
> For a less artificial setup, I tried some 4K test streams. For example:
>
> $ ./ffmpeg_g -v 55 -y -i ~/video/test/LG\ New\ York\ HDR\ UHD\ 4K\ Demo.ts -
> an -init_hw_device vaapi:/dev/dri/renderD128 -vf 'format=nv12,hwupload' -c:v
> h264_vaapi -b:v 24M -max_frame_size 10 out.mp4 2>&1 | grep 'Output
> buffer:' | nl | tee out ...
> $ cat out | awk '{ if ($7 > 10) { print } }'
> 308 [h264_vaapi @ 0x5653126613c0] Output buffer: 118390 bytes (status
> 0433).
> 361 [h264_vaapi @ 0x5653126613c0] Output buffer: 139404 bytes (status
> 042d).
> 481 [h264_vaapi @ 0x5653126613c0] Output buffer: 117728 bytes (status
> 0433).
> 601 [h264_vaapi @ 0x5653126613c0] Output buffer: 117328 bytes (status
> 0432).
> 721 [h264_vaapi @ 0x5653126613c0] Output buffer: 124737 bytes (status
> 042d).
> 841 [h264_vaapi @ 0x5653126613c0] Output buffer: 109479 bytes (status
> 042a).
> 961 [h264_vaapi @ 0x5653126613c0] Output buffer: 128128 bytes (status
> 042b).
>1081 [h264_vaapi @ 0x5653126613c0] Output buffer: 103071 bytes (status
> 0431).
>1201 [h264_vaapi @ 0x5653126613c0] Output buffer: 115270 bytes (status
> 0430).
>1321 [h264_vaapi @ 0x5653126613c0] Output buffer: 154613 bytes (status
> 0430).
>1406 [h264_vaapi @ 0x5653126613c0] Output buffer: 114548 bytes (status
> 0432).
>1441 [h264_vaapi @ 0x5653126613c0] Output buffer: 133374 bytes (status
> 0433).
>1561 [h264_vaapi @ 0x5653126613c0] Output buffer: 150675 bytes (status
> 042f).
>1681 [h264_vaapi @ 0x5653126613c0] Output buffer: 119443 bytes (status
> 042a).
>
> (With average QPs there indicating that it's usually nowhere near 51 when it
> misses the target. Most of those failures are on GOP-start intra frames
> (default
> GOP size is 120), but not all of them.)
>
> > Max frame size was enabled since VA-API version (0, 33, 0), but query
> > is available since (1, 5, 0). It will be passed as a parameter in
> > picParam and should be set for each frame.
> >
> > Signed-off-by: Linjie Fu
> > Si
[FFmpeg-devel] [PATCH v7 1/2] lavc/vaapi_encode: add support for maxframesize
From: Linjie Fu
Add support for max frame size:
- max_frame_size (bytes) to indicate the max allowed size for frame.
Control each encoded frame size into target limitation size by adjusting
whole frame's average QP value. The driver will use multi passes to
adjust average QP setp by step to achieve the target, and the result
may not strictly guaranteed. Frame size may exceed target alone with
using the maximum average QP value. The failure always happens on the
intra(especially the first intra frame of a new GOP) frames or set
max_frame_size with a very small number.
example cmdline:
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -f rawvideo \
-v verbose -s:v 352x288 -i ./input.yuv -vf format=nv12,hwupload \
-c:v h264_vaapi -profile:v main -g 30 -rc_mode VBR -b:v 500k \
-bf 3 -max_frame_size 4 -vframes 100 -y ./max_frame_size.h264
Max frame size was enabled since VA-API version (0, 33, 0), but query
is available since (1, 5, 0). It will be passed as a parameter in picParam
and should be set for each frame.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
update:
1. return error when fail to set max frame size.
2. refine commit and debug message.
libavcodec/vaapi_encode.c | 74 +++
libavcodec/vaapi_encode.h | 10 +-
2 files changed, 83 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 0e2f5ed447..284ce29888 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -365,6 +365,17 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
goto fail;
}
+#if VA_CHECK_VERSION(1, 5, 0)
+if (ctx->max_frame_size) {
+err = vaapi_encode_make_misc_param_buffer(avctx, pic,
+
VAEncMiscParameterTypeMaxFrameSize,
+ &ctx->mfs_params,
+ sizeof(ctx->mfs_params));
+if (err < 0)
+goto fail;
+}
+#endif
+
if (pic->type == PICTURE_TYPE_IDR) {
if (ctx->va_packed_headers & VA_ENC_PACKED_HEADER_SEQUENCE &&
ctx->codec->write_sequence_header) {
@@ -1869,6 +1880,63 @@ rc_mode_found:
return 0;
}
+static av_cold int vaapi_encode_init_max_frame_size(AVCodecContext *avctx)
+{
+#if VA_CHECK_VERSION(1, 5, 0)
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VAConfigAttrib attr = { VAConfigAttribMaxFrameSize };
+VAStatus vas;
+
+if (ctx->va_rc_mode == VA_RC_CQP) {
+ctx->max_frame_size = 0;
+av_log(avctx, AV_LOG_ERROR, "Max frame size is invalid in CQP rate "
+ "control mode.\n");
+return AVERROR(EINVAL);
+}
+
+vas = vaGetConfigAttributes(ctx->hwctx->display,
+ctx->va_profile,
+ctx->va_entrypoint,
+&attr, 1);
+if (vas != VA_STATUS_SUCCESS) {
+ctx->max_frame_size = 0;
+av_log(avctx, AV_LOG_ERROR, "Failed to query max frame size "
+ "config attribute: %d (%s).\n", vas, vaErrorStr(vas));
+return AVERROR_EXTERNAL;
+}
+
+if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
+ctx->max_frame_size = 0;
+av_log(avctx, AV_LOG_ERROR, "Max frame size attribute "
+ "is not supported.\n");
+return AVERROR(EINVAL);
+} else {
+VAConfigAttribValMaxFrameSize attr_mfs;
+attr_mfs.value = attr.value;
+// Prefer to use VAEncMiscParameterTypeMaxFrameSize for max frame size.
+if (!attr_mfs.bits.max_frame_size && attr_mfs.bits.multiple_pass) {
+ctx->max_frame_size = 0;
+av_log(avctx, AV_LOG_ERROR, "Driver only supports multiple pass "
+ "max frame size which has not been implemented in
FFmpeg.\n");
+return AVERROR(EINVAL);
+}
+
+ctx->mfs_params = (VAEncMiscParameterBufferMaxFrameSize){
+.max_frame_size = ctx->max_frame_size * 8,
+};
+
+av_log(avctx, AV_LOG_VERBOSE, "Set max frame size: %d bytes.\n",
+ ctx->max_frame_size);
+}
+#else
+av_log(avctx, AV_LOG_ERROR, "The max frame size option is not supported
with "
+ "this VAAPI version.\n");
+return AVERROR(EINVAL);
+#endif
+
+return 0;
+}
+
static av_cold int vaapi_encode_init_gop_structure(AVCodecContext *avctx)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -2548,6 +2616,12 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
goto fail;
}
+if (ctx->max_frame_size) {
+err = vaapi_encode_init_max_frame_size(avctx);
+if (err < 0)
+goto fail;
+}
+
vas = vaCreateConfig(ctx->hwctx->display,
ctx->va_profile, ctx->va_entrypoint,
ctx->config_attributes, ctx->nb_config_attributes,
diff --git a/lib
[FFmpeg-devel] [PATCH v7 2/2] doc/vaapi_encode: add documentations for max_frame_size
From: Linjie Fu Add docs for max_frame_size option. Signed-off-by: Linjie Fu Signed-off-by: Fei Wang --- doc/encoders.texi | 5 + 1 file changed, 5 insertions(+) diff --git a/doc/encoders.texi b/doc/encoders.texi index 966032a720..43f6288e33 100644 --- a/doc/encoders.texi +++ b/doc/encoders.texi @@ -3665,6 +3665,11 @@ performance. This option doesn't work if driver doesn't implement vaSyncBuffer function. Please make sure there are enough hw_frames allocated if a large number of async_depth is used. +@item max_frame_size +Set the allowed max size in bytes for each frame. If the frame size exceeds +the limitation, encoder will adjust the QP value to control the frame size. +Invalid in CQP rate control mode. + @item rc_mode Set the rate control mode to use. A given driver may only support a subset of modes. -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
> > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > Sent: Sunday, May 1, 2022 5:54 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > > fix the uninitialized texture bindflag > > > > On Sun, May 1, 2022 at 5:48 PM Hendrik Leppkes > > wrote: > > > > > > On Sun, May 1, 2022 at 7:09 AM Soft Works > > wrote: > > > > I think that's what Hendrik wanted to point out as far as I > > understood. > > > > > > > > > > Basically, I want explicit behavior, not implicit defaults. Anytime > > a > > > hwcontext is created, something should tell it what its going to be > > > used for, so we can determine which flags make sense (or ideally, it > > > should just specify the flags). > > > > > > This patch creates an implicit default for one use-case, is this > > going > > > to work with all others? No, of course not, because it has to know > > > what flags to set. Thats why explicitly setting those flags is > > > important, instead of just fixing one implicit case. > > I said I agree with you - basically, just that we need to differentiate > between > the use case: > > 1. Use via API >=> No defaults should be applied, caller is responsible for specifying > the flags > > 2. Use via ffmpeg cli >=> Applying the render target flag would be safe here. > We could require this to set via parameter, but there won't ever > be a case to specify something different than the render target flag > > Why? Let's look at the possible flags: > > D3D11_BIND_DECODER > In all decoding cases, this flag is set explicitly, so it overrides any > default we > would set > > D3D11_BIND_VIDEO_ENCODER > Set explicitly when required, so it overrides any default we would set > > D3D11_BIND_RENDER_TARGET > All other cases require this flag (e.g. video processing) > > No Flag > Dead end, texture would be unusable for any kind of video processing > > > > On that note, the example commandline it fixes just does hwupload and > > nothing else - does that even require render target to be flagged? > > From what I can tell it uses a simple > > ID3D11DeviceContext::CopySubresourceRegion to copy from the staging > > texture, which should not require any particular bind flags. Bind > > Flags in turn would then depend on what you are actually trying to do > > with the texture (shader input, etc), in this example... nothing? > > We are still in the context of ffmpeg cli - you know that there are no shaders > or 3d operations and no etc. > > But at this point, you can derive to another context or you can hwmap. > For all of those things, you need D3D11_BIND_RENDER_TARGET. > > > Summary > > As mentioned I see two possibilities: > > 1. Use D3D11_BIND_RENDER_TARGET as a default when used in context of >ffmpeg cli, otherwise no default flags > > 2. Require a device initialization parameter in the command line >(but it would always be about setting the render target flag >and there's no case where you would NOT want to set it) > Thanks for the possible solutions for this issue. The No.1 seems more reasonable because No.2 just seems more unnecessary. But I will still need to find a better place to set the flag. Before that I am going to resubmit the other 4 patches which have less comments and objections for further review. Thanks, Tong > Let me know what you think. > > Best 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". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] lavc/pgs_frame_merge_bsf: add bsf to merge PGS segments
From: John Stebbins
Required to remux m2ts to mkv
Minor changes and porting to FFBitStreamFilter done by the committer.
Signed-off-by: Andreas Rheinhardt
---
Changelog| 1 +
doc/bitstream_filters.texi | 8 ++
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/pgs_frame_merge_bsf.c | 191 +++
libavcodec/version.h | 2 +-
6 files changed, 203 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/pgs_frame_merge_bsf.c
diff --git a/Changelog b/Changelog
index 4d467eb741..1bae64075e 100644
--- a/Changelog
+++ b/Changelog
@@ -14,6 +14,7 @@ version 5.1:
- colormap video filter
- colorchart video source filter
- blurdetect filter
+- PGS subtitle frame merge bitstream filter
version 5.0:
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index fc2c71fc12..50c95f035d 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -695,6 +695,14 @@ for NTSC frame rate using the @option{frame_rate} option.
ffmpeg -f lavfi -i sine=r=48000:d=1 -c pcm_s16le -bsf pcm_rechunk=r=3/1001
-f framecrc -
@end example
+@section pgs_frame_merge
+
+Merge a sequence of PGS Subtitle segments ending with an "end of display set"
+segment into a single packet.
+
+This is required by some containers that support PGS subtitles
+(muxer @code{matroska}).
+
@section prores_metadata
Modify color property metadata embedded in prores stream.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cfaa6f196a..3c0ff2dc58 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1195,6 +1195,7 @@ OBJS-$(CONFIG_NOISE_BSF) += noise_bsf.o
OBJS-$(CONFIG_NULL_BSF) += null_bsf.o
OBJS-$(CONFIG_OPUS_METADATA_BSF) += opus_metadata_bsf.o
OBJS-$(CONFIG_PCM_RECHUNK_BSF)+= pcm_rechunk_bsf.o
+OBJS-$(CONFIG_PGS_FRAME_MERGE_BSF)+= pgs_frame_merge_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o av1_parse.o
OBJS-$(CONFIG_SETTS_BSF) += setts_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index f117bc0e17..23ae93 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -52,6 +52,7 @@ extern const FFBitStreamFilter ff_noise_bsf;
extern const FFBitStreamFilter ff_null_bsf;
extern const FFBitStreamFilter ff_opus_metadata_bsf;
extern const FFBitStreamFilter ff_pcm_rechunk_bsf;
+extern const FFBitStreamFilter ff_pgs_frame_merge_bsf;
extern const FFBitStreamFilter ff_prores_metadata_bsf;
extern const FFBitStreamFilter ff_remove_extradata_bsf;
extern const FFBitStreamFilter ff_setts_bsf;
diff --git a/libavcodec/pgs_frame_merge_bsf.c b/libavcodec/pgs_frame_merge_bsf.c
new file mode 100644
index 00..bcd8945335
--- /dev/null
+++ b/libavcodec/pgs_frame_merge_bsf.c
@@ -0,0 +1,191 @@
+/*
+ * Copyright (c) 2020 John Stebbins
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * This bitstream filter merges PGS subtitle packets containing incomplete
+ * set of segments into a single packet
+ *
+ * Packets already containing a complete set of segments will be passed through
+ * unchanged.
+ */
+
+#include "libavutil/attributes.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/log.h"
+#include "bsf.h"
+#include "bsf_internal.h"
+
+enum PGSSegmentType {
+PALETTE_SEGMENT = 0x14,
+OBJECT_SEGMENT = 0x15,
+PRESENTATION_SEGMENT= 0x16,
+WINDOW_SEGMENT = 0x17,
+END_DISPLAY_SET_SEGMENT = 0x80,
+};
+
+typedef struct PGSMergeContext {
+AVPacket *buffer_pkt, *in;
+int presentation_found;
+int pkt_flags;
+} PGSMergeContext;
+
+static av_cold void frame_merge_flush(AVBSFContext *bsf)
+{
+PGSMergeContext *ctx = bsf->priv_data;
+
+ctx->presentation_found = ctx->pkt_flags = 0;
+av_packet_unref(ctx->in);
+av_packet_unref(ctx->buffer_pkt);
+}
+
+static int frame_merge_output(PGSMergeContext *ctx, AVPacket *dst, AVPacket
*src)
+{
+if (!ctx->presentation_found)
+ctx->pkt_flags |= AV_PKT_FLAG_CORRUPT;
+ctx->presentation_fo
[FFmpeg-devel] [PATCH 2/3] lavf/matroskaenc: enable PGS merge auto bsf
From: John Stebbins
PGS segments must be merged to one packet for muxing to mkv
Signed-off-by: Andreas Rheinhardt
---
configure | 2 +-
libavformat/matroskaenc.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 196873c4aa..4d2f4d9112 100755
--- a/configure
+++ b/configure
@@ -3435,7 +3435,7 @@ latm_muxer_select="aac_adtstoasc_bsf mpeg4audio"
matroska_audio_muxer_select="matroska_muxer"
matroska_demuxer_select="riffdec"
matroska_demuxer_suggest="bzlib zlib"
-matroska_muxer_select="mpeg4audio riffenc vp9_superframe_bsf aac_adtstoasc_bsf"
+matroska_muxer_select="mpeg4audio riffenc aac_adtstoasc_bsf
pgs_frame_merge_bsf vp9_superframe_bsf"
mlp_demuxer_select="mlp_parser"
mmf_muxer_select="riffenc"
mov_demuxer_select="iso_media riffdec"
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 3b8ca11f28..fe296197b1 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -3172,6 +3172,9 @@ static int mkv_check_bitstream(AVFormatContext *s,
AVStream *st,
ret = ff_stream_add_bitstream_filter(st, "aac_adtstoasc", NULL);
} else if (st->codecpar->codec_id == AV_CODEC_ID_VP9) {
ret = ff_stream_add_bitstream_filter(st, "vp9_superframe", NULL);
+} else if (CONFIG_MATROSKA_MUXER &&
+ st->codecpar->codec_id == AV_CODEC_ID_HDMV_PGS_SUBTITLE) {
+ret = ff_stream_add_bitstream_filter(st, "pgs_frame_merge", NULL);
}
return ret;
--
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 3/3] fate/matroska: Add tests for muxing PGS into Matroska
They test the new pgs_frame_merge BSF. Signed-off-by: Andreas Rheinhardt --- tests/fate/matroska.mak | 8 tests/ref/fate/matroska-pgs-remux | 7 +++ tests/ref/fate/matroska-pgs-remux-durations | 7 +++ 3 files changed, 22 insertions(+) create mode 100644 tests/ref/fate/matroska-pgs-remux create mode 100644 tests/ref/fate/matroska-pgs-remux-durations diff --git a/tests/fate/matroska.mak b/tests/fate/matroska.mak index c9d88975ca..7baf85f29e 100644 --- a/tests/fate/matroska.mak +++ b/tests/fate/matroska.mak @@ -163,6 +163,14 @@ FATE_MATROSKA_FFMPEG_FFPROBE-$(call REMUX, MATROSKA, MPEGTS_DEMUXER AC3_DECODER) += fate-matroska-mpegts-remux fate-matroska-mpegts-remux: CMD = transcode mpegts $(TARGET_SAMPLES)/mpegts/pmtchange.ts matroska "-map 0:2 -map 0:2 -c copy -disposition:a:1 -visual_impaired+hearing_impaired -default_mode infer" "-map 0 -c copy" "" "-show_entries stream_disposition:stream=index" +FATE_MATROSKA-$(call REMUX, MATROSKA, SUP_DEMUXER) += fate-matroska-pgs-remux +fate-matroska-pgs-remux: CMD = transcode sup $(TARGET_SAMPLES)/sub/pgs_sub.sup matroska "-copyts -c:s copy" "-copyts -c:s copy" + +# This test uses the setts bsf to derive the duration of every packet +# except the last from the next packet's pts. +FATE_MATROSKA-$(call REMUX, MATROSKA, SUP_DEMUXER PGS_FRAME_MERGE_BSF SETTS_BSF) += fate-matroska-pgs-remux-durations +fate-matroska-pgs-remux-durations: CMD = transcode sup $(TARGET_SAMPLES)/sub/pgs_sub.sup matroska "-copyts -c:s copy -bsf pgs_frame_merge,setts=duration=if(gt(DURATION\,0)\,DURATION\,if(eq(PTS\,NOPTS)\,0\,if(eq(NEXT_PTS\,NOPTS)\,0\,NEXT_PTS-PTS))):pts=PTS" "-copyts -c:s copy" + FATE_MATROSKA_FFPROBE-$(call ALLYES, MATROSKA_DEMUXER) += fate-matroska-spherical-mono fate-matroska-spherical-mono: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries stream_side_data_list -select_streams v -v 0 $(TARGET_SAMPLES)/mkv/spherical.mkv diff --git a/tests/ref/fate/matroska-pgs-remux b/tests/ref/fate/matroska-pgs-remux new file mode 100644 index 00..4fab0ffdd8 --- /dev/null +++ b/tests/ref/fate/matroska-pgs-remux @@ -0,0 +1,7 @@ +9aa538611b5f3bd0455b2afd3dafe08d *tests/data/fate/matroska-pgs-remux.matroska +49751 tests/data/fate/matroska-pgs-remux.matroska +#tb 0: 1/1000 +#media_type 0: subtitle +#codec_id 0: hdmv_pgs_subtitle +0, 67, 67,0,26127, 0x02389441 +0,401,401,0,23155, 0x1de74712 diff --git a/tests/ref/fate/matroska-pgs-remux-durations b/tests/ref/fate/matroska-pgs-remux-durations new file mode 100644 index 00..ba649d0ddf --- /dev/null +++ b/tests/ref/fate/matroska-pgs-remux-durations @@ -0,0 +1,7 @@ +20fa9d515b08718c42d3e3a8a4a8bf5d *tests/data/fate/matroska-pgs-remux-durations.matroska +49763 tests/data/fate/matroska-pgs-remux-durations.matroska +#tb 0: 1/1000 +#media_type 0: subtitle +#codec_id 0: hdmv_pgs_subtitle +0, 67, 67, 334,26127, 0x02389441 +0,401,401,0,23155, 0x1de74712 -- 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 v3 1/4] 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 | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index b28dcffe2a..65af7130b8 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1281,12 +1281,23 @@ static int qsv_frames_derive_from(AVHWFramesContext
*dst_ctx,
#if CONFIG_D3D11VA
case AV_HWDEVICE_TYPE_D3D11VA:
{
+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 (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;
+if (dst_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET) {
+dst_hwctx->texture_infos[i].index = 0;
+}
+else {
+dst_hwctx->texture_infos[i].index = (intptr_t)pair->second;
+}
+}
}
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 v3 4/4] avutil/hwcontext_qsv: map D3D11VA frames to QSV 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 | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 27eedef5f8..30d3360d42 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1885,7 +1885,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 v3 2/4] 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 v3 3/4] avutil/hwcontext_qsv: map QSV frames to D3D11VA frames
When input is a rawvideo, after mapping QSV frames to D3D11VA frames,
the output will have green frames. Now fix it.
Fixes:
$ ffmpeg.exe -y -init_hw_device d3d11va=d3d11 \
-init_hw_device qsv=qsv@d3d11 -s:v WxH -pix_fmt nv12 -i input.yuv \
-vf "format=nv12,hwupload=extra_hw_frames=16,\
hwmap=derive_device=d3d11va,format=d3d11,hwdownload,format=nv12" \
-f rawvideo output.yuv
Signed-off-by: Tong Wu
---
libavutil/hwcontext_qsv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 65af7130b8..27eedef5f8 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -1388,7 +1388,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;
}
@@ -1418,7 +1418,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;
}
--
2.35.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v15 4/4] avformat/image2: add Jpeg XL as image2 format
On Thu, May 5, 2022 at 5:49 AM Leo Izen wrote: > On 5/4/22 17:56, Mark Gaiser wrote: > > Hi, > > > > I might have found a bug here. Or I might not be using it correctly, > that's > > entirely possible too! > > What i try is just making an animated jxl from a bunch of input images. > > Currently animated JXL is not supported. > Yeah, I noticed ;) But is that a limitation on the implementation side within ffmpeg or the libjxl side? In either case the error could perhaps be more descriptive as it currently makes you believe you've done something wrong in the command arguments. Also, thank you so much for your efforts in getting this in ffmpeg! > - 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 mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Thursday, May 5, 2022 12:53 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v3 1/4] 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 | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index b28dcffe2a..65af7130b8 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1281,12 +1281,23 @@ static int
> qsv_frames_derive_from(AVHWFramesContext *dst_ctx,
> #if CONFIG_D3D11VA
> case AV_HWDEVICE_TYPE_D3D11VA:
> {
> +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 (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);
This is not right. QSV frames are not only created from here
(hwcontext_qsv) but also from qsvvpp.c AND also by MSDK internally
as VPP output frames, which means that we cannot assume the rules
we are using here being followed.
You need to query those flags from the (first) texture instead.
> +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;
> +if (dst_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET)
> {
> +dst_hwctx->texture_infos[i].index = 0;
> +}
> +else {
> +dst_hwctx->texture_infos[i].index =
> (intptr_t)pair->second;
> +}
> +}
Same as above here. With MSDK it is not guaranteed that VPP
output frames will be array textures. This depends on the MSDK
runtime version.
They always have the flag D3D11_BIND_RENDER_TARGET, so that's
not an appropriate condition.
I would check .second for MFX_INFINITE instead.
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 v3 4/4] avutil/hwcontext_qsv: map D3D11VA frames to QSV frames
> -Original Message-
> From: ffmpeg-devel On Behalf Of Tong
> Wu
> Sent: Thursday, May 5, 2022 12:53 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Tong Wu
> Subject: [FFmpeg-devel] [PATCH v3 4/4] avutil/hwcontext_qsv: map
> D3D11VA frames to QSV 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 | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 27eedef5f8..30d3360d42 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -1885,7 +1885,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;
> }
> --
I think this patch should be squashed together with patch 3/4 because
mapping is kind of broken between those two commits.
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".
[FFmpeg-devel] [PATCH] avformat/avformat: Schedule AVOutputFormat.data_codec for removal
No AVOutputFormat has this set. It is not removed immediately despite
being private because of the libavdevice<->libavformat situation.
The fact that this field is private is also the reason why no FF_API_*
define has been added.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avformat.h | 2 ++
libavformat/format.c | 2 --
libavformat/utils.c| 3 +--
3 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index f12fa7d904..69d1d0fa3d 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -614,7 +614,9 @@ typedef struct AVOutputFormat {
* @see avdevice_list_devices() for more details.
*/
int (*get_device_list)(struct AVFormatContext *s, struct AVDeviceInfoList
*device_list);
+#if LIBAVFORMAT_VERSION_MAJOR < 60
enum AVCodecID data_codec; /**< default data codec */
+#endif
/**
* Initialize format. May allocate data here, and set any AVFormatContext
or
* AVStream parameters that need to be set before packets are sent.
diff --git a/libavformat/format.c b/libavformat/format.c
index 4b1f3c2986..76f25ab5a6 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -111,8 +111,6 @@ enum AVCodecID av_guess_codec(const AVOutputFormat *fmt,
const char *short_name,
return fmt->audio_codec;
else if (type == AVMEDIA_TYPE_SUBTITLE)
return fmt->subtitle_codec;
-else if (type == AVMEDIA_TYPE_DATA)
-return fmt->data_codec;
else
return AV_CODEC_ID_NONE;
}
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 3f253c2045..7fbc3a4a18 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1293,8 +1293,7 @@ int avformat_query_codec(const AVOutputFormat *ofmt, enum
AVCodecID codec_id,
return !!av_codec_get_tag2(ofmt->codec_tag, codec_id, &codec_tag);
else if (codec_id == ofmt->video_codec ||
codec_id == ofmt->audio_codec ||
- codec_id == ofmt->subtitle_codec ||
- codec_id == ofmt->data_codec)
+ codec_id == ofmt->subtitle_codec)
return 1;
}
return AVERROR_PATCHWELCOME;
--
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".
Re: [FFmpeg-devel] [PATCH] avformat/avformat: Schedule AVOutputFormat.data_codec for removal
Hi Andreas, On Thu, May 5, 2022 at 2:47 PM Andreas Rheinhardt wrote: > > No AVOutputFormat has this set. It is not removed immediately despite > being private because of the libavdevice<->libavformat situation. > The fact that this field is private is also the reason why no FF_API_* > define has been added. Since you bring up the libavdevice<->libavformat situation, allow me to plug this patch again https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294747.html. https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/294746.html has links to previous discussions of the issue. I hope you and others who chimed in before (e.g., Nicolas, Anton) have a chance to look at this potential solution. Thanks and all the best, Dee ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] fate/lavf-audio: Disable CRC for lavf-peak_only.wav test
Andreas Rheinhardt:
> The output of this test is just a file containing the positions
> of peaks; it is not a wave file and trying to demuxing it just
> returns AVERROR_INVALIDDATA; said error has just been ignored
> as the return value from do_avconv_crc is the return value from echo.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> tests/fate-run.sh| 3 ++-
> tests/fate/lavf-audio.mak| 2 +-
> tests/ref/lavf/peak_only.wav | 1 -
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index 821e949b01..c206a439b2 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -312,7 +312,8 @@ lavf_audio(){
> outdir="tests/data/lavf"
> file=${outdir}/lavf.$t
> do_avconv $file -auto_conversion_filters $DEC_OPTS $1 -ar 44100 -f s16le
> -i $pcm_src "$ENC_OPTS -metadata title=lavftest" -t 1 -qscale 10 $2
> -do_avconv_crc $file -auto_conversion_filters $DEC_OPTS $3 -i
> $target_path/$file
> +test "$4" = "disable_crc" ||
> +do_avconv_crc $file -auto_conversion_filters $DEC_OPTS $3 -i
> $target_path/$file
> }
>
> lavf_container(){
> diff --git a/tests/fate/lavf-audio.mak b/tests/fate/lavf-audio.mak
> index b03030176c..68fca35298 100644
> --- a/tests/fate/lavf-audio.mak
> +++ b/tests/fate/lavf-audio.mak
> @@ -34,7 +34,7 @@ fate-lavf-ast: CMD = lavf_audio "-ac 2" "-loopstart 1
> -loopend 10"
> fate-lavf-mka: CMD = lavf_audio "" "-c:a tta"
> fate-lavf-voc: CMD = lavf_audio "" "-c:a pcm_u8"
> fate-lavf-peak.wav: CMD = lavf_audio "" "-write_peak on"
> -fate-lavf-peak_only.wav: CMD = lavf_audio "" "-write_peak only"
> +fate-lavf-peak_only.wav: CMD = lavf_audio "" "-write_peak only" ""
> disable_crc
>
> FATE_AVCONV += $(FATE_LAVF_AUDIO)
> fate-lavf-audio fate-lavf: $(FATE_LAVF_AUDIO)
> diff --git a/tests/ref/lavf/peak_only.wav b/tests/ref/lavf/peak_only.wav
> index c468731b00..9548e639f8 100644
> --- a/tests/ref/lavf/peak_only.wav
> +++ b/tests/ref/lavf/peak_only.wav
> @@ -1,3 +1,2 @@
> f1a8aeeae8069f3992c4d780436c3d23 *tests/data/lavf/lavf.peak_only.wav
> 832 tests/data/lavf/lavf.peak_only.wav
> -tests/data/lavf/lavf.peak_only.wav
Will apply this patchset tomorrow unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v5 0/2] JPEG XL Colorspace Fixes
Changes v5: - fix attaching ICCP even if an enum can accurately describe the colorspace v4: - fix a typo. bluh v3: - some cosmetic changes - properly handle P3 spaces - properly handle PQ transfer v2: - avoid misusing AVMasteringDisplayMetadata - ignore custom primaries in header (very rare without iccp) Leo Izen (2): avcodec/libjxldec: properly tag output colorspace avcodec/libjxlenc: properly read input colorspace libavcodec/libjxldec.c | 113 +--- libavcodec/libjxlenc.c | 128 ++--- 2 files changed, 201 insertions(+), 40 deletions(-) -- 2.36.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 v5 1/2] avcodec/libjxldec: properly tag output colorspace
Whether an ICC profile is present or not, the decoder
should now properly tag the colorspace of pixel data
received by the decoder.
---
libavcodec/libjxldec.c | 113 ++---
1 file changed, 105 insertions(+), 8 deletions(-)
diff --git a/libavcodec/libjxldec.c b/libavcodec/libjxldec.c
index cd4bca3343..813ee279fe 100644
--- a/libavcodec/libjxldec.c
+++ b/libavcodec/libjxldec.c
@@ -135,6 +135,7 @@ static int libjxl_decode_frame(AVCodecContext *avctx,
AVFrame *frame, int *got_f
uint8_t *buf = avpkt->data;
size_t remaining = avpkt->size, iccp_len;
JxlDecoderStatus jret;
+JxlColorEncoding jxl_encoding;
int ret;
*got_frame = 0;
@@ -189,16 +190,112 @@ static int libjxl_decode_frame(AVCodecContext *avctx,
AVFrame *frame, int *got_f
continue;
case JXL_DEC_COLOR_ENCODING:
av_log(avctx, AV_LOG_DEBUG, "COLOR_ENCODING event emitted\n");
-jret = JxlDecoderGetICCProfileSize(ctx->decoder, &ctx->jxl_pixfmt,
JXL_COLOR_PROFILE_TARGET_ORIGINAL, &iccp_len);
-if (jret == JXL_DEC_SUCCESS && iccp_len > 0) {
-av_buffer_unref(&ctx->iccp);
-ctx->iccp = av_buffer_alloc(iccp_len);
-if (!ctx->iccp)
-return AVERROR(ENOMEM);
-jret = JxlDecoderGetColorAsICCProfile(ctx->decoder,
&ctx->jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_ORIGINAL, ctx->iccp->data, iccp_len);
-if (jret != JXL_DEC_SUCCESS)
+jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder, NULL,
JXL_COLOR_PROFILE_TARGET_ORIGINAL, &jxl_encoding);
+if (jret == JXL_DEC_SUCCESS)
+jret = JxlDecoderSetPreferredColorProfile(ctx->decoder,
&jxl_encoding);
+if (jret == JXL_DEC_SUCCESS)
+jret = JxlDecoderGetColorAsEncodedProfile(ctx->decoder,
&ctx->jxl_pixfmt, JXL_COLOR_PROFILE_TARGET_DATA, &jxl_encoding);
+
+avctx->color_range = frame->color_range = AVCOL_RANGE_JPEG;
+
+if (jret == JXL_DEC_SUCCESS) {
+if (ctx->jxl_pixfmt.num_channels >= 3) {
+avctx->colorspace = AVCOL_SPC_RGB;
+switch (jxl_encoding.primaries) {
+case JXL_PRIMARIES_SRGB:
+avctx->color_primaries = AVCOL_PRI_BT709;
+break;
+case JXL_PRIMARIES_2100:
+/* BT2020 and BT2100 use the same primaries */
+avctx->color_primaries = AVCOL_PRI_BT2020;
+break;
+case JXL_PRIMARIES_P3:
+/* DCI P3 uses DCI, Display P3 uses D65 */
+if (jxl_encoding.white_point == JXL_WHITE_POINT_DCI) {
+avctx->color_primaries = AVCOL_PRI_SMPTE431;
+} else if (jxl_encoding.white_point ==
JXL_WHITE_POINT_D65) {
+avctx->color_primaries = AVCOL_PRI_SMPTE432;
+} else {
+av_log(avctx, AV_LOG_WARNING, "Unsupported JXL
white point: %d\n", jxl_encoding.white_point);
+jret = JXL_DEC_ERROR;
+}
+break;
+case JXL_PRIMARIES_CUSTOM:
+av_log(avctx, AV_LOG_WARNING, "Custom primaries are
unsupported without an ICC profile\n");
+jret = JXL_DEC_ERROR;
+break;
+default:
+av_log(avctx, AV_LOG_WARNING, "Unknown JXL color
primaries: %d\n", jxl_encoding.primaries);
+jret = JXL_DEC_ERROR;
+}
+}
+
+switch (jxl_encoding.transfer_function) {
+case JXL_TRANSFER_FUNCTION_709:
+avctx->color_trc = AVCOL_TRC_BT709;
+break;
+case JXL_TRANSFER_FUNCTION_LINEAR:
+avctx->color_trc = AVCOL_TRC_LINEAR;
+break;
+case JXL_TRANSFER_FUNCTION_SRGB:
+avctx->color_trc = AVCOL_TRC_IEC61966_2_1;
+break;
+case JXL_TRANSFER_FUNCTION_PQ:
+avctx->color_trc = AVCOL_TRC_SMPTE2084;
+break;
+case JXL_TRANSFER_FUNCTION_DCI:
+avctx->color_trc = AVCOL_TRC_SMPTE428;
+break;
+case JXL_TRANSFER_FUNCTION_HLG:
+avctx->color_trc = AVCOL_TRC_ARIB_STD_B67;
+break;
+case JXL_TRANSFER_FUNCTION_GAMMA:
+if (jxl_encoding.gamma == 2.2) {
+avctx->color_trc = AVCOL_TRC_GAMMA22;
+} else if (jxl_encoding.gamma == 2.8) {
+avctx->color_trc = AVCOL_TRC_GAMMA28;
+} else {
+
[FFmpeg-devel] [PATCH v5 2/2] avcodec/libjxlenc: properly read input colorspace
Whether an ICC profile is present or not, the libjxl
encoder wrapper should now properly read colorspace tags
and forward them to libjxl appropriately, rather than just
assume sRGB as before. It will also print warnings when
colorimetric assumptions are made about the input data.
---
libavcodec/libjxlenc.c | 128 ++---
1 file changed, 96 insertions(+), 32 deletions(-)
diff --git a/libavcodec/libjxlenc.c b/libavcodec/libjxlenc.c
index 8bebec6aeb..43bb7299c6 100644
--- a/libavcodec/libjxlenc.c
+++ b/libavcodec/libjxlenc.c
@@ -117,7 +117,7 @@ static int libjxl_init_jxl_encoder(AVCodecContext *avctx)
return AVERROR_EXTERNAL;
}
-/* check for negative zero, our default */
+/* check for negative, our default */
if (ctx->distance < 0.0) {
/* use ffmpeg.c -q option if passed */
if (avctx->flags & AV_CODEC_FLAG_QSCALE)
@@ -133,7 +133,8 @@ static int libjxl_init_jxl_encoder(AVCodecContext *avctx)
*/
if (ctx->distance > 0.0 && ctx->distance < 0.01)
ctx->distance = 0.01;
-if (JxlEncoderOptionsSetDistance(ctx->options, ctx->distance) !=
JXL_ENC_SUCCESS) {
+
+if (JxlEncoderSetFrameDistance(ctx->options, ctx->distance) !=
JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set distance: %f\n",
ctx->distance);
return AVERROR_EXTERNAL;
}
@@ -219,57 +220,120 @@ static int libjxl_encode_frame(AVCodecContext *avctx,
AVPacket *pkt, const AVFra
info.num_color_channels = jxl_fmt.num_channels - info.num_extra_channels;
info.bits_per_sample = av_get_bits_per_pixel(pix_desc) /
jxl_fmt.num_channels;
info.alpha_bits = (info.num_extra_channels > 0) * info.bits_per_sample;
+
if (pix_desc->flags & AV_PIX_FMT_FLAG_FLOAT) {
info.exponent_bits_per_sample = info.bits_per_sample > 16 ? 8 : 5;
info.alpha_exponent_bits = info.alpha_bits ?
info.exponent_bits_per_sample : 0;
jxl_fmt.data_type = info.bits_per_sample > 16 ? JXL_TYPE_FLOAT :
JXL_TYPE_FLOAT16;
-JxlColorEncodingSetToLinearSRGB(&jxl_color, info.num_color_channels ==
1);
} else {
info.exponent_bits_per_sample = 0;
info.alpha_exponent_bits = 0;
jxl_fmt.data_type = info.bits_per_sample <= 8 ? JXL_TYPE_UINT8 :
JXL_TYPE_UINT16;
-JxlColorEncodingSetToSRGB(&jxl_color, info.num_color_channels == 1);
}
-if (info.bits_per_sample > 16
-|| info.xsize > (1 << 18) || info.ysize > (1 << 18)
-|| (info.xsize << 4) * (info.ysize << 4) > (1 << 20)) {
-/*
- * must upgrade codestream to level 10, from level 5
- * the encoder will not do this automatically
- */
-if (JxlEncoderSetCodestreamLevel(ctx->encoder, 10) != JXL_ENC_SUCCESS)
{
-av_log(avctx, AV_LOG_ERROR, "Could not upgrade JXL Codestream
level.\n");
-return AVERROR_EXTERNAL;
-}
-}
+/* JPEG XL format itself does not support partial range */
+if (avctx->color_range == AVCOL_RANGE_MPEG)
+av_log(avctx, AV_LOG_ERROR, "This encoder does not support partial(tv)
range, colors will be wrong!\n");
+else if (avctx->color_range != AVCOL_RANGE_JPEG)
+av_log(avctx, AV_LOG_WARNING, "Unknown color range, assuming full\n");
-/* bitexact lossless requires there to be no XYB transform */
+ /* bitexact lossless requires there to be no XYB transform */
info.uses_original_profile = ctx->distance == 0.0;
-sd = av_frame_get_side_data(frame, AV_FRAME_DATA_ICC_PROFILE);
-if (sd && sd->size && JxlEncoderSetICCProfile(ctx->encoder, sd->data,
sd->size) != JXL_ENC_SUCCESS) {
-av_log(avctx, AV_LOG_WARNING, "Could not set ICC Profile\n");
-} else if (info.uses_original_profile) {
-/*
-* the color encoding is not used if uses_original_profile is false
-* this just works around a bug in libjxl 0.7.0 and lower
-*/
-if (JxlEncoderSetColorEncoding(ctx->encoder, &jxl_color) !=
JXL_ENC_SUCCESS) {
-av_log(avctx, AV_LOG_ERROR, "Failed to set JxlColorEncoding\n");
-return AVERROR_EXTERNAL;
-}
-}
-
if (JxlEncoderSetBasicInfo(ctx->encoder, &info) != JXL_ENC_SUCCESS) {
av_log(avctx, AV_LOG_ERROR, "Failed to set JxlBasicInfo\n");
return AVERROR_EXTERNAL;
}
+/* rendering intent doesn't matter here
+ * but libjxl will whine if we don't set it */
+jxl_color.rendering_intent = JXL_RENDERING_INTENT_RELATIVE;
+
+switch (avctx->color_trc) {
+case AVCOL_TRC_BT709:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_709;
+break;
+case AVCOL_TRC_LINEAR:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_LINEAR;
+break;
+case AVCOL_TRC_IEC61966_2_1:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_SRGB;
+break;
+case AVCOL_TRC_SMPTE428:
+jxl_color.transfer_function = JXL_TRANSFER_FUNCTION_DCI;
+
Re: [FFmpeg-devel] [PATCH v11 1/6] libavutil/wchar_filename.h: Add whcartoutf8, wchartoansi and utf8toansi
> Yes, because there is no realistic case in which ffmpeg will need > to load any dll from a long path. > I've asked you multiple times to give an example. Managed to find time to actually test: https://postimg.cc/F1C64nq1. Windows 10 21H2 LTSC, long paths are enabled and 8.3 paths are disabled via group policy. CMD is capable of starting applications from long paths: test app prints get_module_filename(). As can be seen from the output, module path is an actual long path, not 8.3 short name. Windows is clearly capable of running apps from long paths. Always was via the first argument to CreateProcess, prefixed with your favourite \\?\. This facility is no longer esoteric and is available to end users via CMD. FFmpeg in its current form doesn't work when started from a long path, even with these patches. It prints nothing and just returns a non-zero exit code. That's a problem with FFmpeg. Something in FFmpeg startup breaks down when running from a long path, though it's not clear exactly what. You're talking about realistic use cases as if someone made a careful analysis of use cases before putting the limit in place. No one did, the limit came from the OS. OS no longer has this limit, so neither should FFmpeg. > So, ffmpeg should implement something that doesn't work without a > registry change in order to "pressure Microsoft" to change it at > some point in the future? Things are implemented in order to provide features, not to pressure someone. You still have to abide by API's contract, however. Long paths are enabled by a registry tweak, and that's how things are. > I apologize when I have created the impression that ffmpeg should > be left as is and users should continue adding the long path prefix > themselves. I'm not opposed to adding support for long paths, I'm > just opposed to the method. As a matter of fact, you are. Your alternative method implies ploughing through hundreds of C files normalising path handling across the entire application, and then fixing numerous regressions introduced along the way. No one is doing that, just too much work. Manifest is the only practically implementable solution, and if it's not accepted, FFmpeg stays as it is and users are forced to continue to manually prefix all paths. Of course, if you think so strongly that \\?\ is the right way to go, then how about writing the necessary patches yourself? And even then I have some bad news for you. MAX_PATH-sized buffers simply do not work with long paths, even the ones that start with \\?\. You will still have to replace them with dynamically allocated buffers. And that's what the majority of this patch-set is about, not about the manifest. Manifest is just a single patch. > Implementing long path support by adding the prefix is not > a "workaround". Those kinds of paths are part of OS functionality > since Windows NT and will still work in Windows 20 or whatever > may come. It is and always was. \\?\ support none of the usual path handling such as relative paths, slash-collapsing, removal of . from paths etc. > Because with the first, you cannot rely that long paths are > working, you would be stuck needing to continue prefixing paths > manually "forever". > (to also cover cases where it's not working) No one is prefixing the paths. Neither end users, nor application writers. If it doesn't work without a prefix, it doesn't work at all, and you end up without any long path support whatsoever. > IIRC this code is handling code paths relative to the executable path, > and the executable doesn't run from a long path anyway. Because it's broken in FFmpeg, not because you cannot run an app from a long path. See above. > > This patchset does not provide reliable behavior. > ... > You know what I meant: it's not activated by default. Not active by default is not the same as not reliable. > What is in the hands of ffmpeg though, is requiring a change which > needs administrative privileges or not. It doesn't require administrative rights. It requires a registry tweak. If you don't have admin rights but still need the feature, you can ask your system administrator. > I don't want to argue about the term lottery. You're perfectly willing to use it. > What I'm saying is that a solution is preferable which doesn't have > an "Otherwise it doesn't" part. As Thomas Sowell has put it: "There are no solutions. There are only trade-offs." Do not pretend that \\?\ is even practical, considering the scope of changes required to implement it. ___ 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] Merge QSV decoder SEI patch into master?
Would it be possible to merge the following patch into the master branch? https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm8p223mb03655f44a7bf01132bb2959dba...@dm8p223mb0365.namp223.prod.outlook.com/ This patch provides the QSV decoder with SEI message and ATSC A/53 caption capability. I understand some time has passed since the patch was originally generated but I was able to apply it with minimal adjustments and the code works as desired in regards to captions. We'd like to see the QSV decoder become more feature complete. If there are any steps necessary to make this happen, please advise. Best regards, Vladislav Sorkin ___ 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] avfilter/alimiter:add latency compensation
Also added 2 FATE tests to verify delay is compenated correctly
Signed-off-by: Wang Cao
---
doc/filters.texi| 5 +++
libavfilter/af_alimiter.c | 90 +
tests/fate/filter-audio.mak | 24 --
3 files changed, 116 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a161754233..75a43edd88 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1978,6 +1978,11 @@ in release time while 1 produces higher release times.
@item level
Auto level output signal. Default is enabled.
This normalizes audio back to 0dB if enabled.
+
+@item latency
+Compensate the delay introduced by using the lookahead buffer set with attack
+parameter. Also flush the valid audio data in the lookahead buffer when the
+stream hits EOF
@end table
Depending on picked setting it is recommended to upsample input 2x or 4x times
diff --git a/libavfilter/af_alimiter.c b/libavfilter/af_alimiter.c
index 133f98f165..01265758d7 100644
--- a/libavfilter/af_alimiter.c
+++ b/libavfilter/af_alimiter.c
@@ -26,6 +26,7 @@
#include "libavutil/channel_layout.h"
#include "libavutil/common.h"
+#include "libavutil/fifo.h"
#include "libavutil/opt.h"
#include "audio.h"
@@ -33,6 +34,11 @@
#include "formats.h"
#include "internal.h"
+typedef struct MetaItem {
+int64_t pts;
+int nb_samples;
+} MetaItem;
+
typedef struct AudioLimiterContext {
const AVClass *class;
@@ -55,6 +61,14 @@ typedef struct AudioLimiterContext {
int *nextpos;
double *nextdelta;
+int in_trim;
+int out_pad;
+int64_t next_in_pts;
+int64_t next_out_pts;
+int latency;
+
+AVFifo *fifo;
+
double delta;
int nextiter;
int nextlen;
@@ -73,6 +87,7 @@ static const AVOption alimiter_options[] = {
{ "asc", "enable asc", OFFSET(auto_release), AV_OPT_TYPE_BOOL,
{.i64=0}, 0,1, AF },
{ "asc_level", "set asc level",OFFSET(asc_coeff),
AV_OPT_TYPE_DOUBLE, {.dbl=0.5},0,1, AF },
{ "level", "auto level", OFFSET(auto_level), AV_OPT_TYPE_BOOL,
{.i64=1}, 0,1, AF },
+{ "latency", "compensate delay", OFFSET(latency), AV_OPT_TYPE_BOOL,
{.i64=0}, 0,1, AF },
{ NULL }
};
@@ -129,6 +144,11 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
AVFrame *out;
double *buf;
int n, c, i;
+int new_out_samples;
+int64_t out_duration;
+int64_t in_duration;
+int64_t in_pts;
+MetaItem meta;
if (av_frame_is_writable(in)) {
out = in;
@@ -269,12 +289,69 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
dst += channels;
}
+in_duration = av_rescale_q(in->nb_samples, inlink->time_base,
av_make_q(1, in->sample_rate));
+in_pts = in->pts;
+meta = (MetaItem){ in->pts, in->nb_samples };
+av_fifo_write(s->fifo, &meta, 1);
if (in != out)
av_frame_free(&in);
+new_out_samples = out->nb_samples;
+if (s->in_trim > 0) {
+int trim = FFMIN(new_out_samples, s->in_trim);
+new_out_samples -= trim;
+s->in_trim -= trim;
+}
+
+if (new_out_samples <= 0) {
+av_frame_free(&out);
+return 0;
+} else if (new_out_samples < out->nb_samples) {
+int offset = out->nb_samples - new_out_samples;
+memmove(out->extended_data[0], out->extended_data[0] + sizeof(double)
* offset * out->ch_layout.nb_channels,
+sizeof(double) * new_out_samples * out->ch_layout.nb_channels);
+out->nb_samples = new_out_samples;
+s->in_trim = 0;
+}
+
+av_fifo_read(s->fifo, &meta, 1);
+
+out_duration = av_rescale_q(out->nb_samples, inlink->time_base,
av_make_q(1, out->sample_rate));
+in_duration = av_rescale_q(meta.nb_samples, inlink->time_base,
av_make_q(1, out->sample_rate));
+in_pts = meta.pts;
+
+if (s->next_out_pts != AV_NOPTS_VALUE && out->pts != s->next_out_pts &&
+s->next_in_pts != AV_NOPTS_VALUE && in_pts == s->next_in_pts) {
+out->pts = s->next_out_pts;
+} else {
+out->pts = in_pts;
+}
+s->next_in_pts = in_pts + in_duration;
+s->next_out_pts = out->pts + out_duration;
+
return ff_filter_frame(outlink, out);
}
+static int request_frame(AVFilterLink* outlink)
+{
+AVFilterContext *ctx = outlink->src;
+AudioLimiterContext *s = (AudioLimiterContext*)ctx->priv;
+int ret;
+
+ret = ff_request_frame(ctx->inputs[0]);
+
+if (ret == AVERROR_EOF && s->out_pad > 0) {
+AVFrame *frame = ff_get_audio_buffer(outlink, FFMIN(1024, s->out_pad));
+if (!frame)
+return AVERROR(ENOMEM);
+
+s->out_pad -= frame->nb_samples;
+frame->pts = s->next_in_pts;
+return filter_frame(ctx->inputs[0], frame);
+}
+return ret;
+}
+
static int config_input(AVFilterLink *inlink)
{
AVFilterContext *ctx = inlink->dst;
@@ -294,6 +371,16 @@ static int config
Re: [FFmpeg-devel] [PATCH] avfilter/alimiter: Add an option "comp_delay" that removes the delay introduced by lookahead buffer
On Mon, May 2, 2022 at 1:24 AM Paul B Mahol wrote:
> On Fri, Apr 29, 2022 at 10:49 PM Wang Cao <
> wangcao-at-google@ffmpeg.org>
> wrote:
>
> > On Fri, Apr 15, 2022 at 11:50 AM Wang Cao wrote:
> >
> > > 1. The option also flushes all the valid audio samples in the lookahead
> > >buffer so the audio integrity is preserved. Previously the the
> output
> > >audio will lose the amount of audio samples equal to the size of
> > >lookahead buffer
> > > 2. Add a FATE test to verify that when the filter is working as
> > >passthrough filter, all audio samples are properly handled from the
> > >input to the output.
> > >
> > > Signed-off-by: Wang Cao
> > > ---
> > > doc/filters.texi| 5 +++
> > > libavfilter/af_alimiter.c | 74 +
> > > tests/fate/filter-audio.mak | 12 ++
> > > 3 files changed, 91 insertions(+)
> > >
> > > diff --git a/doc/filters.texi b/doc/filters.texi
> > > index a161754233..2af0953c89 100644
> > > --- a/doc/filters.texi
> > > +++ b/doc/filters.texi
> > > @@ -1978,6 +1978,11 @@ in release time while 1 produces higher release
> > > times.
> > > @item level
> > > Auto level output signal. Default is enabled.
> > > This normalizes audio back to 0dB if enabled.
> > > +
> > > +@item comp_delay
> > > +Compensate the delay introduced by using the lookahead buffer set with
> > > attack
> > > +parameter. Also flush the valid audio data in the lookahead buffer
> when
> > > the
> > > +stream hits EOF.
> > > @end table
> > >
> > > Depending on picked setting it is recommended to upsample input 2x or
> 4x
> > > times
> > > diff --git a/libavfilter/af_alimiter.c b/libavfilter/af_alimiter.c
> > > index 133f98f165..d10a90859b 100644
> > > --- a/libavfilter/af_alimiter.c
> > > +++ b/libavfilter/af_alimiter.c
> > > @@ -55,6 +55,12 @@ typedef struct AudioLimiterContext {
> > > int *nextpos;
> > > double *nextdelta;
> > >
> > > +int lookahead_delay_samples;
> > > +int lookahead_flush_samples;
> > > +int64_t output_pts;
> > > +int64_t next_output_pts;
> > > +int comp_delay;
> > > +
> > > double delta;
> > > int nextiter;
> > > int nextlen;
> > > @@ -73,6 +79,7 @@ static const AVOption alimiter_options[] = {
> > > { "asc", "enable asc", OFFSET(auto_release),
> > > AV_OPT_TYPE_BOOL, {.i64=0}, 0,1, AF },
> > > { "asc_level", "set asc level",OFFSET(asc_coeff),
> > > AV_OPT_TYPE_DOUBLE, {.dbl=0.5},0,1, AF },
> > > { "level", "auto level", OFFSET(auto_level),
> > > AV_OPT_TYPE_BOOL, {.i64=1}, 0,1, AF },
> > > +{ "comp_delay","compensate delay", OFFSET(comp_delay),
> > > AV_OPT_TYPE_BOOL, {.i64=0}, 0,1, AF },
> > > { NULL }
> > > };
> > >
> > > @@ -129,6 +136,8 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame
> > > *in)
> > > AVFrame *out;
> > > double *buf;
> > > int n, c, i;
> > > +int num_output_samples = in->nb_samples;
> > > +int trim_offset;
> > >
> > > if (av_frame_is_writable(in)) {
> > > out = in;
> > > @@ -271,10 +280,71 @@ static int filter_frame(AVFilterLink *inlink,
> > > AVFrame *in)
> > >
> > > if (in != out)
> > > av_frame_free(&in);
> > > +
> > > +if (!s->comp_delay) {
> > > +return ff_filter_frame(outlink, out);
> > > +}
> > > +
> > > +if (s->output_pts == AV_NOPTS_VALUE) {
> > > +s->output_pts = in->pts;
> > > +}
> > > +
> > > +if (s->lookahead_delay_samples > 0) {
> > > +// The current output frame is completely silence
> > > +if (s->lookahead_delay_samples >= in->nb_samples) {
> > > +s->lookahead_delay_samples -= in->nb_samples;
> > > +return 0;
> > > +}
> > > +
> > > +// Trim the silence part
> > > +trim_offset = av_samples_get_buffer_size(
> > > +NULL, inlink->ch_layout.nb_channels,
> > > s->lookahead_delay_samples,
> > > +(enum AVSampleFormat)out->format, 1);
> > > +out->data[0] += trim_offset;
> > > +out->nb_samples = in->nb_samples - s->lookahead_delay_samples;
> > > +s->lookahead_delay_samples = 0;
> > > +num_output_samples = out->nb_samples;
> > > +}
> > > +
> > > +if (s->lookahead_delay_samples < 0) {
> > > +return AVERROR_BUG;
> > > +}
> > > +
> > > +out->pts = s->output_pts;
> > > +s->next_output_pts = s->output_pts + num_output_samples;
> > > +s->output_pts = s->next_output_pts;
> > >
> > > return ff_filter_frame(outlink, out);
> > > }
> > >
> > > +static int request_frame(AVFilterLink* outlink)
> > > +{
> > > +AVFilterContext *ctx = outlink->src;
> > > +AudioLimiterContext *s = (AudioLimiterContext*)ctx->priv;
> > > +int ret;
> > > +AVFilterLink *inlink;
> > > +AVFrame *silence_frame;
> > > +
> > > +ret = ff_request_frame(ctx->inputs[0]);
> > > +
> > > +if (ret != AVERROR_EOF || s->lookahea
Re: [FFmpeg-devel] [PATCH 1/3] avfilter/vf_libplacebo: Match AV_OPT_TYPE_FLOAT to dbl
On Wed, May 04, 2022 at 11:49:01PM +0800, myp...@gmail.com wrote:
> On Wed, May 4, 2022 at 11:37 PM Michael Niedermayer
> wrote:
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavfilter/vf_libplacebo.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavfilter/vf_libplacebo.c b/libavfilter/vf_libplacebo.c
> > index 5bcdd64d84..cfee1117e8 100644
> > --- a/libavfilter/vf_libplacebo.c
> > +++ b/libavfilter/vf_libplacebo.c
> > @@ -718,7 +718,7 @@ static const AVOption libplacebo_options[] = {
> >
> > /* Performance/quality tradeoff options */
> > { "skip_aa", "Skip anti-aliasing", OFFSET(skip_aa), AV_OPT_TYPE_BOOL,
> > {.i64 = 0}, 0, 0, DYNAMIC },
> > -{ "polar_cutoff", "Polar LUT cutoff", OFFSET(polar_cutoff),
> > AV_OPT_TYPE_FLOAT, {.i64 = 0}, 0.0, 1.0, DYNAMIC },
> > +{ "polar_cutoff", "Polar LUT cutoff", OFFSET(polar_cutoff),
> > AV_OPT_TYPE_FLOAT, {.dbl = 0}, 0.0, 1.0, DYNAMIC },
> > { "disable_linear", "Disable linear scaling", OFFSET(disable_linear),
> > AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
> > { "disable_builtin", "Disable built-in scalers",
> > OFFSET(disable_builtin), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, DYNAMIC },
> > { "force_icc_lut", "Force the use of a full ICC 3DLUT for color
> > mapping", OFFSET(force_icc_lut), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
> > DYNAMIC },
> > --
> > 2.17.1
> >
> Patchset looks good, thx
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Merge QSV decoder SEI patch into master?
> -Original Message- > From: ffmpeg-devel On Behalf Of > Vladislav Sorkin > Sent: Thursday, May 5, 2022 10:48 PM > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] Merge QSV decoder SEI patch into master? > > Would it be possible to merge the following patch into the master > branch? > https://patchwork.ffmpeg.org/project/ffmpeg/patch/DM8P223MB03655F44A7B > f01132bb2959dba...@dm8p223mb0365.namp223.prod.outlook.com/ > > This patch provides the QSV decoder with SEI message and ATSC A/53 > caption > capability. > > I understand some time has passed since the patch was originally > generated > but I was able to apply it with minimal adjustments and the code works > as > desired in regards to captions. > > We'd like to see the QSV decoder become more feature complete. > > If there are any steps necessary to make this happen, please advise. There's still a pending issue which I'm waiting to get resolved: https://github.com/Intel-Media-SDK/MediaSDK/issues/2597 (not the OP, start from the bottom) Second part that needs to be done is some re-ordering to properly associate SEI data with frames in case B-frames are used. (as Haihao had pointed out) It's not forgotten, though. 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 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: Thursday, May 5, 2022 10:20 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. > And even then I have some bad news for you. MAX_PATH-sized buffers > simply do not work > with long paths, even the ones that start with \\?\. You will still > have to replace > them with dynamically allocated buffers. And that's what the majority > of this patch-set Why should that be bad news for me? Those are three very specific cases and we had already covered this. I had also said that it surely makes sense to eliminate fixed size buffers. But that's all just distraction from the main subject, which is "Long Path Support in ffmpeg on Windows". My point is very simple: It should be a solution that will always work and not just sometimes. I stripped the remaining points because this is just going in circles. My opinion should be sufficiently explained by now, and I'd like to leave room for other opinions. 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".
[FFmpeg-devel] [PATCH] avformat/oggparsevorbis: Fix oggvorbis duration parsing for small files
The decoded Data is not returned from the first frame; it must be used
to 'prime' the decode engine. The duration of the first packet should
be ignored also by the container, to make sure the total duration is
trimmed correctly.
If the file has multiple pages for the data packets. The duration of the
last packet can be correctly adjusted without being affected by the first
packet. But if the first packet and the last packet are located in the
same page, the duration of the last packet will have an unwanted offset.
This commit fixes https://trac.ffmpeg.org/ticket/6367.
dd if=/dev/zero of=./silence.raw count=1 bs=500
oggenc --raw silence.raw --output=silence.ogg
oggdec --raw --output silence.oggdec.raw silence.ogg
ffmpeg -codec:a libvorbis -i silence.ogg -f s16le -codec:a pcm_s16le
silence.libvorbis.ffmpeg.raw
ffmpeg -i silence.ogg -f s16le -codec:a pcm_s16le silence.native.ffmpeg.raw
ls -l *.raw
Signed-off-by: Guangyu Sun
---
libavformat/oggparsevorbis.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
index 289900f7cf..9a486c9fe8 100644
--- a/libavformat/oggparsevorbis.c
+++ b/libavformat/oggparsevorbis.c
@@ -412,6 +412,7 @@ static int vorbis_packet(AVFormatContext *s, int idx)
struct ogg_stream *os = ogg->streams + idx;
struct oggvorbis_private *priv = os->private;
int duration, flags = 0;
+int first_page;
if (!priv->vp)
return AVERROR_INVALIDDATA;
@@ -420,7 +421,8 @@ static int vorbis_packet(AVFormatContext *s, int idx)
* here we parse the duration of each packet in the first page and compare
* the total duration to the page granule to find the encoder delay and
* set the first timestamp */
-if ((!os->lastpts || os->lastpts == AV_NOPTS_VALUE) && !(os->flags &
OGG_FLAG_EOS) && (int64_t)os->granule>=0) {
+first_page = !os->lastpts || os->lastpts == AV_NOPTS_VALUE;
+if (first_page && !(os->flags & OGG_FLAG_EOS) && (int64_t)os->granule>=0) {
int seg, d;
uint8_t *last_pkt = os->buf + os->pstart;
uint8_t *next_pkt = last_pkt;
@@ -479,6 +481,13 @@ static int vorbis_packet(AVFormatContext *s, int idx)
flags = 0;
}
os->pduration = duration;
+/* Data is not returned from the first frame; it must be used to
'prime'
+ * the decode engine. The duration of the first packet should be
ignored
+ * also by the container, to make sure the total duration is trimmed
+ * correctly.
+ */
+if (first_page && os->segp == 1)
+os->pduration = 0;
}
/* final packet handling
--
2.30.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/4] avutil/hwcontext_qsv: derive QSV frames to D3D11VA frames
> -Original Message-
> From: Soft Works
> Sent: Thursday, May 5, 2022 7:53 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Wu, Tong1
> Subject: RE: [FFmpeg-devel] [PATCH v3 1/4] avutil/hwcontext_qsv: derive
> QSV frames to D3D11VA frames
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Tong
> > Wu
> > Sent: Thursday, May 5, 2022 12:53 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Tong Wu
> > Subject: [FFmpeg-devel] [PATCH v3 1/4] 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 | 15 +--
> > 1 file changed, 13 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index b28dcffe2a..65af7130b8 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -1281,12 +1281,23 @@ static int
> > qsv_frames_derive_from(AVHWFramesContext *dst_ctx, #if
> CONFIG_D3D11VA
> > case AV_HWDEVICE_TYPE_D3D11VA:
> > {
> > +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 (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);
>
> This is not right. QSV frames are not only created from here
> (hwcontext_qsv) but also from qsvvpp.c AND also by MSDK internally as VPP
> output frames, which means that we cannot assume the rules we are using
> here being followed.
>
> You need to query those flags from the (first) texture instead.
>
Thanks, will resubmit the patchset.
>
> > +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;
> > +if (dst_hwctx->BindFlags & D3D11_BIND_RENDER_TARGET)
> > {
> > +dst_hwctx->texture_infos[i].index = 0;
> > +}
> > +else {
> > +dst_hwctx->texture_infos[i].index =
> > (intptr_t)pair->second;
> > +}
> > +}
>
> Same as above here. With MSDK it is not guaranteed that VPP output frames
> will be array textures. This depends on the MSDK runtime version.
> They always have the flag D3D11_BIND_RENDER_TARGET, so that's not an
> appropriate condition.
>
> I would check .second for MFX_INFINITE instead.
>
> 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 v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
> -Original Message- > From: ffmpeg-devel On Behalf Of Wu, > Tong1 > Sent: Thursday, May 5, 2022 11:50 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > fix the uninitialized texture bindflag > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Hendrik Leppkes > > > Sent: Sunday, May 1, 2022 5:54 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > avutil/hwcontext_d3d11va: > > > fix the uninitialized texture bindflag > > > > > > On Sun, May 1, 2022 at 5:48 PM Hendrik Leppkes > > > > wrote: > > > > > > > > On Sun, May 1, 2022 at 7:09 AM Soft Works > > > > wrote: > > > > > I think that's what Hendrik wanted to point out as far as I > > > understood. > > > > > > > > > > > > > Basically, I want explicit behavior, not implicit defaults. > Anytime > > > a > > > > hwcontext is created, something should tell it what its going to > be > > > > used for, so we can determine which flags make sense (or > ideally, it > > > > should just specify the flags). > > > > > > > > This patch creates an implicit default for one use-case, is this > > > going > > > > to work with all others? No, of course not, because it has to > know > > > > what flags to set. Thats why explicitly setting those flags is > > > > important, instead of just fixing one implicit case. > > > > I said I agree with you - basically, just that we need to > differentiate between > > the use case: > > > > 1. Use via API > >=> No defaults should be applied, caller is responsible for > specifying > > the flags > > > > 2. Use via ffmpeg cli > >=> Applying the render target flag would be safe here. > > We could require this to set via parameter, but there won't > ever > > be a case to specify something different than the render > target flag > > > > Why? Let's look at the possible flags: > > > > D3D11_BIND_DECODER > > In all decoding cases, this flag is set explicitly, so it overrides > any default we > > would set > > > > D3D11_BIND_VIDEO_ENCODER > > Set explicitly when required, so it overrides any default we would > set > > > > D3D11_BIND_RENDER_TARGET > > All other cases require this flag (e.g. video processing) > > > > No Flag > > Dead end, texture would be unusable for any kind of video processing > > > > > > > On that note, the example commandline it fixes just does hwupload > and > > > nothing else - does that even require render target to be flagged? > > > From what I can tell it uses a simple > > > ID3D11DeviceContext::CopySubresourceRegion to copy from the > staging > > > texture, which should not require any particular bind flags. Bind > > > Flags in turn would then depend on what you are actually trying to > do > > > with the texture (shader input, etc), in this example... nothing? > > > > We are still in the context of ffmpeg cli - you know that there are > no shaders > > or 3d operations and no etc. > > > > But at this point, you can derive to another context or you can > hwmap. > > For all of those things, you need D3D11_BIND_RENDER_TARGET. > > > > > > Summary > > > > As mentioned I see two possibilities: > > > > 1. Use D3D11_BIND_RENDER_TARGET as a default when used in context of > >ffmpeg cli, otherwise no default flags > > > > 2. Require a device initialization parameter in the command line > >(but it would always be about setting the render target flag > >and there's no case where you would NOT want to set it) > > > > Thanks for the possible solutions for this issue. The No.1 seems more > reasonable because > No.2 just seems more unnecessary. But I will still need to find a > better place to set the flag. I would favor #1 as well. Regarding "better place to set the flag": The BindFlag needs to be set when initializing a FRAMES context. But at this point, there's no way to determine whether the code is running in an ffmpeg cli process or used by an API consumer. But there would be an opportunity to convey this information on device init. The device (D3D11VA) could then set an internal flag from device init and use this on frames init to determine which default to use for the BindFlags value. Remains the question how ffmpeg cli can convey this information to the device (for use during device init). What I thought would be to have ffmpeg.c (or rather ffmpeg_hw.c) to ALWAYS (for all hwaccels) add an entry to the options dictionary, something like "cli" or similar. This would avoid introducing a "special-case" mechanism just for this case (=> by making it a common behavior). There are other cases where this might be useful in order to discriminate API usage from cli usage. But let's see what the others think first.. Kind regards, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel T
[FFmpeg-devel] [PATCH] libavcodec/qsvenc: Add min/max QP control options for I/P/B frame
From: Yue Heng
To do more accurate QP control, add min/max QP control on I/P/B frame
separately to qsv encoder. qmax and qmin still work but newly-added
options have higher priority.
Signed-off-by: Yue Heng
Signed-off-by: Wenbin Chen
---
doc/encoders.texi | 18 ++
libavcodec/qsvenc.c | 21 +++--
libavcodec/qsvenc.h | 12
3 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 966032a720..86bcdbc04b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3282,6 +3282,24 @@ Forcing I frames as IDR frames.
@item @var{low_power}
For encoders set this flag to ON to reduce power consumption and GPU usage.
+
+@item @var{max_qp_i}
+Maximum video quantizer scale for I frame.
+
+@item @var{min_qp_i}
+Minimum video quantizer scale for I frame.
+
+@item @var{max_qp_p}
+Maximum video quantizer scale for P frame.
+
+@item @var{min_qp_p}
+Minimum video quantizer scale for P frame.
+
+@item @var{max_qp_b}
+Maximum video quantizer scale for B frame.
+
+@item @var{min_qp_b}
+Minimum video quantizer scale for B frame.
@end table
@subsection H264 options
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index fbb22ca436..a3e9bb4583 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -930,8 +930,13 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
q->extco2.BRefType = q->b_strategy ? MFX_B_REF_PYRAMID :
MFX_B_REF_OFF;
#endif
#if QSV_VERSION_ATLEAST(1, 9)
-if (avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
avctx->qmax) {
-av_log(avctx, AV_LOG_ERROR, "qmin and or qmax are set but
invalid, please make sure min <= max\n");
+if ((avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
avctx->qmax) ||
+(q->max_qp_i >= 0 && q->min_qp_i >= 0 && q->min_qp_i >
q->max_qp_i) ||
+(q->max_qp_p >= 0 && q->min_qp_p >= 0 && q->min_qp_p >
q->max_qp_p) ||
+(q->max_qp_b >= 0 && q->min_qp_b >= 0 && q->min_qp_b >
q->max_qp_b)) {
+av_log(avctx, AV_LOG_ERROR,
+ "qmin and or qmax are set but invalid,"
+ " please make sure min <= max\n");
return AVERROR(EINVAL);
}
if (avctx->qmin >= 0) {
@@ -942,6 +947,18 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
q->extco2.MaxQPI = avctx->qmax > 51 ? 51 : avctx->qmax;
q->extco2.MaxQPP = q->extco2.MaxQPB = q->extco2.MaxQPI;
}
+if (q->min_qp_i >= 0)
+q->extco2.MinQPI = q->min_qp_i > 51 ? 51 : q->min_qp_i;
+if (q->max_qp_i >= 0)
+q->extco2.MaxQPI = q->max_qp_i > 51 ? 51 : q->max_qp_i;
+if (q->min_qp_p >= 0)
+q->extco2.MinQPP = q->min_qp_p > 51 ? 51 : q->min_qp_p;
+if (q->max_qp_p >= 0)
+q->extco2.MaxQPP = q->max_qp_p > 51 ? 51 : q->max_qp_p;
+if (q->min_qp_b >= 0)
+q->extco2.MinQPB = q->min_qp_b > 51 ? 51 : q->min_qp_b;
+if (q->max_qp_b >= 0)
+q->extco2.MaxQPB = q->max_qp_b > 51 ? 51 : q->max_qp_b;
#endif
if (q->mbbrc >= 0)
q->extco2.MBBRC = q->mbbrc ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index cb84723dfa..ea05967db5 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -105,6 +105,12 @@
{ "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_qp_i", "Maximum video quantizer scale for I frame",
OFFSET(qsv.max_qp_i), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51,
VE}, \
+{ "min_qp_i", "Minimum video quantizer scale for I frame",
OFFSET(qsv.min_qp_i), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51,
VE}, \
+{ "max_qp_p", "Maximum video quantizer scale for P frame",
OFFSET(qsv.max_qp_p), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51,
VE}, \
+{ "min_qp_p", "Minimum video quantizer scale for P frame",
OFFSET(qsv.min_qp_p), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51,
VE}, \
+{ "max_qp_b", "Maximum video quantizer scale for B frame",
OFFSET(qsv.max_qp_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51,
VE}, \
+{ "min_qp_b", "Minimum video quantizer scale for B frame",
Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
On Fri, May 6, 2022 at 3:11 AM Soft Works wrote: > > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of Wu, > > Tong1 > > Sent: Thursday, May 5, 2022 11:50 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > > fix the uninitialized texture bindflag > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > Sent: Sunday, May 1, 2022 5:54 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > > avutil/hwcontext_d3d11va: > > > > fix the uninitialized texture bindflag > > > > > > > > On Sun, May 1, 2022 at 5:48 PM Hendrik Leppkes > > > > > > wrote: > > > > > > > > > > On Sun, May 1, 2022 at 7:09 AM Soft Works > > > > > > wrote: > > > > > > I think that's what Hendrik wanted to point out as far as I > > > > understood. > > > > > > > > > > > > > > > > Basically, I want explicit behavior, not implicit defaults. > > Anytime > > > > a > > > > > hwcontext is created, something should tell it what its going to > > be > > > > > used for, so we can determine which flags make sense (or > > ideally, it > > > > > should just specify the flags). > > > > > > > > > > This patch creates an implicit default for one use-case, is this > > > > going > > > > > to work with all others? No, of course not, because it has to > > know > > > > > what flags to set. Thats why explicitly setting those flags is > > > > > important, instead of just fixing one implicit case. > > > > > > I said I agree with you - basically, just that we need to > > differentiate between > > > the use case: > > > > > > 1. Use via API > > >=> No defaults should be applied, caller is responsible for > > specifying > > > the flags > > > > > > 2. Use via ffmpeg cli > > >=> Applying the render target flag would be safe here. > > > We could require this to set via parameter, but there won't > > ever > > > be a case to specify something different than the render > > target flag > > > > > > Why? Let's look at the possible flags: > > > > > > D3D11_BIND_DECODER > > > In all decoding cases, this flag is set explicitly, so it overrides > > any default we > > > would set > > > > > > D3D11_BIND_VIDEO_ENCODER > > > Set explicitly when required, so it overrides any default we would > > set > > > > > > D3D11_BIND_RENDER_TARGET > > > All other cases require this flag (e.g. video processing) > > > > > > No Flag > > > Dead end, texture would be unusable for any kind of video processing > > > > > > > > > > On that note, the example commandline it fixes just does hwupload > > and > > > > nothing else - does that even require render target to be flagged? > > > > From what I can tell it uses a simple > > > > ID3D11DeviceContext::CopySubresourceRegion to copy from the > > staging > > > > texture, which should not require any particular bind flags. Bind > > > > Flags in turn would then depend on what you are actually trying to > > do > > > > with the texture (shader input, etc), in this example... nothing? > > > > > > We are still in the context of ffmpeg cli - you know that there are > > no shaders > > > or 3d operations and no etc. > > > > > > But at this point, you can derive to another context or you can > > hwmap. > > > For all of those things, you need D3D11_BIND_RENDER_TARGET. > > > > > > > > > Summary > > > > > > As mentioned I see two possibilities: > > > > > > 1. Use D3D11_BIND_RENDER_TARGET as a default when used in context of > > >ffmpeg cli, otherwise no default flags > > > > > > 2. Require a device initialization parameter in the command line > > >(but it would always be about setting the render target flag > > >and there's no case where you would NOT want to set it) > > > > > > > Thanks for the possible solutions for this issue. The No.1 seems more > > reasonable because > > No.2 just seems more unnecessary. But I will still need to find a > > better place to set the flag. > > I would favor #1 as well. > > Regarding "better place to set the flag": > > The BindFlag needs to be set when initializing a FRAMES context. > But at this point, there's no way to determine whether the code is running > in an ffmpeg cli process or used by an API consumer. > > But there would be an opportunity to convey this information on > device init. The device (D3D11VA) could then set an internal flag > from device init and use this on frames init to determine which default > to use for the BindFlags value. > > Remains the question how ffmpeg cli can convey this information to > the device (for use during device init). > > What I thought would be to have ffmpeg.c (or rather ffmpeg_hw.c) > to ALWAYS (for all hwaccels) add an entry to the options dictionary, > something like "cli" or similar. > This would avoid introducing a "special-case" mechanism just for > this case (=> by making it a common behavior). > >
[FFmpeg-devel] [PATCH] libavcodec/qsvenc: add ROI support to qsv encoder
Use the mfxEncoderCtrl parameter to enable ROI. Get side data
"AVRegionOfInterest"
from filter "addroi" and use it to configure "mfxExtEncoderROI" which is
the MediaSDK's ROI configuration.
Signed-off-by: Wenbin Chen
---
libavcodec/qsv_internal.h | 4 ++
libavcodec/qsvenc.c | 88 +++
2 files changed, 92 insertions(+)
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index e2aecdcbd6..8131acdae9 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -51,6 +51,9 @@
#define ASYNC_DEPTH_DEFAULT 4 // internal parallelism
#define QSV_MAX_ENC_PAYLOAD 2 // # of mfxEncodeCtrl payloads supported
+#define QSV_MAX_ENC_EXTPARAM 2
+
+#define QSV_MAX_ROI_NUM 256
#define QSV_MAX_FRAME_EXT_PARAMS 4
@@ -83,6 +86,7 @@ typedef struct QSVFrame {
int num_ext_params;
mfxPayload *payloads[QSV_MAX_ENC_PAYLOAD]; ///< used for enc_ctrl.Payload
+mfxExtBuffer *extparam[QSV_MAX_ENC_EXTPARAM]; ///< used for
enc_ctrl.ExtParam
int queued;
int used;
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index fbb22ca436..9abead604b 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -1501,15 +1501,29 @@ static void free_encoder_ctrl_payloads(mfxEncodeCtrl*
enc_ctrl)
}
}
+static void free_encoder_ctrl_extparam(mfxEncodeCtrl* enc_ctrl)
+{
+if (enc_ctrl) {
+int i;
+for (i = 0; i < enc_ctrl->NumExtParam && i < QSV_MAX_ENC_EXTPARAM;
i++) {
+if (enc_ctrl->ExtParam[i])
+av_freep(&(enc_ctrl->ExtParam[i]));
+}
+enc_ctrl->NumExtParam = 0;
+}
+}
+
static void clear_unused_frames(QSVEncContext *q)
{
QSVFrame *cur = q->work_frames;
while (cur) {
if (cur->used && !cur->surface.Data.Locked) {
free_encoder_ctrl_payloads(&cur->enc_ctrl);
+free_encoder_ctrl_extparam(&cur->enc_ctrl);
//do not reuse enc_ctrl from previous frame
memset(&cur->enc_ctrl, 0, sizeof(cur->enc_ctrl));
cur->enc_ctrl.Payload = cur->payloads;
+cur->enc_ctrl.ExtParam = cur->extparam;
if (cur->frame->format == AV_PIX_FMT_QSV) {
av_frame_unref(cur->frame);
}
@@ -1547,6 +1561,7 @@ static int get_free_frame(QSVEncContext *q, QSVFrame **f)
return AVERROR(ENOMEM);
}
frame->enc_ctrl.Payload = frame->payloads;
+frame->enc_ctrl.ExtParam = frame->extparam;
*last = frame;
*f = frame;
@@ -1648,6 +1663,70 @@ static void print_interlace_msg(AVCodecContext *avctx,
QSVEncContext *q)
}
}
+static int set_roi_encode_ctrl(AVCodecContext *avctx, const AVFrame *frame,
+ mfxEncodeCtrl *enc_ctrl)
+{
+#if QSV_VERSION_ATLEAST(1, 22)
+AVFrameSideData *sd = NULL;
+int mb_size;
+
+if (avctx->codec_id == AV_CODEC_ID_H264) {
+mb_size = 16;
+} else if (avctx->codec_id == AV_CODEC_ID_H265) {
+mb_size = 32;
+} else {
+return 0;
+}
+
+if (frame)
+sd = av_frame_get_side_data(frame, AV_FRAME_DATA_REGIONS_OF_INTEREST);
+
+if (sd) {
+mfxExtEncoderROI *enc_roi = NULL;
+AVRegionOfInterest *roi;
+uint32_t roi_size;
+int nb_roi, i;
+
+roi = (AVRegionOfInterest *)sd->data;
+roi_size = roi->self_size;
+if (!roi_size || sd->size % roi_size) {
+av_log(avctx, AV_LOG_ERROR, "Invalid ROI Data.\n");
+return AVERROR(EINVAL);
+}
+nb_roi = sd->size / roi_size;
+if (nb_roi > QSV_MAX_ROI_NUM) {
+av_log(avctx, AV_LOG_WARNING, "More ROIs set than "
+"supported by driver (%d > %d).\n",
+nb_roi, QSV_MAX_ROI_NUM);
+nb_roi = QSV_MAX_ROI_NUM;
+}
+
+enc_roi = av_mallocz(sizeof(*enc_roi));
+if (!enc_roi)
+return AVERROR(ENOMEM);
+enc_roi->Header.BufferId = MFX_EXTBUFF_ENCODER_ROI;
+enc_roi->Header.BufferSz = sizeof(*enc_roi);
+enc_roi->NumROI = nb_roi;
+enc_roi->ROIMode = MFX_ROI_MODE_QP_DELTA;
+for (i = 0; i < nb_roi; i++) {
+roi = (AVRegionOfInterest *)(sd->data + roi_size * i);
+enc_roi->ROI[i].Top= FFALIGN(roi->top, mb_size);
+enc_roi->ROI[i].Bottom = FFALIGN(roi->bottom, mb_size);
+enc_roi->ROI[i].Left = FFALIGN(roi->left, mb_size);
+enc_roi->ROI[i].Right = FFALIGN(roi->right, mb_size);
+enc_roi->ROI[i].DeltaQP =
+roi->qoffset.num * 51 / roi->qoffset.den;
+av_log(avctx, AV_LOG_DEBUG, "ROI: (%d,%d)-(%d,%d) -> %+d.\n",
+ roi->top, roi->left, roi->bottom, roi->right,
+ enc_roi->ROI[i].DeltaQP);
+}
+enc_ctrl->ExtParam[enc_ctrl->NumExtParam] = (mfxExtBuffer *)enc_roi;
+enc_ctrl->NumExtParam++;
+}
+#endif
+return 0;
+}
+
static int encode_frame(AVCo
Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: fix the uninitialized texture bindflag
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Friday, May 6, 2022 7:38 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] avutil/hwcontext_d3d11va: > fix the uninitialized texture bindflag > > On Fri, May 6, 2022 at 3:11 AM Soft Works > wrote: > > > > > > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > Wu, > > > Tong1 > > > Sent: Thursday, May 5, 2022 11:50 AM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > avutil/hwcontext_d3d11va: > > > fix the uninitialized texture bindflag > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On Behalf > Of > > > > > Hendrik Leppkes > > > > > Sent: Sunday, May 1, 2022 5:54 PM > > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [PATCH v2 1/5] > > > avutil/hwcontext_d3d11va: > > > > > fix the uninitialized texture bindflag > > > > > > > > > > On Sun, May 1, 2022 at 5:48 PM Hendrik Leppkes > > > > > > > > wrote: > > > > > > > > > > > > On Sun, May 1, 2022 at 7:09 AM Soft Works > > > > > > > > wrote: > > > > > > > I think that's what Hendrik wanted to point out as far as > I > > > > > understood. > > > > > > > > > > > > > > > > > > > Basically, I want explicit behavior, not implicit defaults. > > > Anytime > > > > > a > > > > > > hwcontext is created, something should tell it what its > going to > > > be > > > > > > used for, so we can determine which flags make sense (or > > > ideally, it > > > > > > should just specify the flags). > > > > > > > > > > > > This patch creates an implicit default for one use-case, is > this > > > > > going > > > > > > to work with all others? No, of course not, because it has > to > > > know > > > > > > what flags to set. Thats why explicitly setting those flags > is > > > > > > important, instead of just fixing one implicit case. > > > > > > > > I said I agree with you - basically, just that we need to > > > differentiate between > > > > the use case: > > > > > > > > 1. Use via API > > > >=> No defaults should be applied, caller is responsible for > > > specifying > > > > the flags > > > > > > > > 2. Use via ffmpeg cli > > > >=> Applying the render target flag would be safe here. > > > > We could require this to set via parameter, but there > won't > > > ever > > > > be a case to specify something different than the render > > > target flag > > > > > > > > Why? Let's look at the possible flags: > > > > > > > > D3D11_BIND_DECODER > > > > In all decoding cases, this flag is set explicitly, so it > overrides > > > any default we > > > > would set > > > > > > > > D3D11_BIND_VIDEO_ENCODER > > > > Set explicitly when required, so it overrides any default we > would > > > set > > > > > > > > D3D11_BIND_RENDER_TARGET > > > > All other cases require this flag (e.g. video processing) > > > > > > > > No Flag > > > > Dead end, texture would be unusable for any kind of video > processing > > > > > > > > > > > > > On that note, the example commandline it fixes just does > hwupload > > > and > > > > > nothing else - does that even require render target to be > flagged? > > > > > From what I can tell it uses a simple > > > > > ID3D11DeviceContext::CopySubresourceRegion to copy from the > > > staging > > > > > texture, which should not require any particular bind flags. > Bind > > > > > Flags in turn would then depend on what you are actually > trying to > > > do > > > > > with the texture (shader input, etc), in this example... > nothing? > > > > > > > > We are still in the context of ffmpeg cli - you know that there > are > > > no shaders > > > > or 3d operations and no etc. > > > > > > > > But at this point, you can derive to another context or you can > > > hwmap. > > > > For all of those things, you need D3D11_BIND_RENDER_TARGET. > > > > > > > > > > > > Summary > > > > > > > > As mentioned I see two possibilities: > > > > > > > > 1. Use D3D11_BIND_RENDER_TARGET as a default when used in > context of > > > >ffmpeg cli, otherwise no default flags > > > > > > > > 2. Require a device initialization parameter in the command line > > > >(but it would always be about setting the render target flag > > > >and there's no case where you would NOT want to set it) > > > > > > > > > > Thanks for the possible solutions for this issue. The No.1 seems > more > > > reasonable because > > > No.2 just seems more unnecessary. But I will still need to find a > > > better place to set the flag. > > > > I would favor #1 as well. > > > > Regarding "better place to set the flag": > > > > The BindFlag needs to be set when initializing a FRAMES context. > > But at this point, there's no way to determine whether the code is > running > > in an ffmpeg cli process or used by an API consumer. > > > > But there would be an opportunity to conv
[FFmpeg-devel] [PATCH v4 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..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));
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);
+}
+}
+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 v4 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 v4 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 bf150c8553..5bff2dbcf2 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] avcodec/jpeg2000: Fast fail if HTJ2K codeblocks are present.
---
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".
