Re: [FFmpeg-devel] [PATCH] libavfilter: vf_scale: Properly take in->color_range into account
On Sat, Mar 05, 2022 at 11:33:15PM +0200, Martin Storsjö wrote: > On Fri, 4 Mar 2022, Michael Niedermayer wrote: > > > On Thu, Mar 03, 2022 at 02:06:45PM +0200, Martin Storsjö wrote: > > > While swscale can be reconfigured with sws_setColorspaceDetails, > > > the in/out ranges also need to be set before calling > > > sws_init_context, otherwise the initialization might choose > > > fastpaths that don't take the ranges into account. > > > > > > Therefore, look at in->color_range too, when deciding on whether > > > the scaler needs to be reconfigured. > > > > > > Add a new member variable for keeping track of this, for being > > > able to differentiate between whether the scale filter parameter > > > "in_range" has been set (which should override whatever the input > > > frame has set) or whether it has been configured based on the > > > latest frame (which should trigger reconfiguring the scaler if > > > the input frame ranges change). > > > > > > Signed-off-by: Martin Storsjö > > > --- > > > To test this (without risking running many conflicting swscale > > > filters in one filter pipeline), we'd need to be able to tag > > > the incoming raw yuv data with colorspace and range without setting > > > the in_color_matrix and in_range options on the scale filter. > > > > > > When using the rawvideo demuxer, the pixel format is set via the > > > ffmpeg -pix_fmt option, but there's no corresponding option for > > > setting color matrix or range for it. > > > --- > > > libavfilter/vf_scale.c | 13 + > > > 1 file changed, 13 insertions(+) > > > > This changes the output for: > > ffmpeg -i tickets/524/AVCI50.mov -vframes 3 file-avci50dec.nut > > ffmpeg -i tickets/4493/AVCI100.mov -vframes 3 file-avci100dec.nut > > > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/ > > > > Is that intended ? > > > > - 233903 file-avci100dec.nut > > - 383853 file-avci50dec.nut > > + 196558 file-avci100dec.nut > > + 333893 file-avci50dec.nut > > Looks like these source files have full range content; for any data with > full range input, this patch makes sure it uses the right intended > conversion through swscale. So yes, I guess it's expected that these > conversions change. patch ok then thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter: vf_scale: Properly take in->color_range into account
On Fri, 4 Mar 2022, Michael Niedermayer wrote: On Thu, Mar 03, 2022 at 02:06:45PM +0200, Martin Storsjö wrote: While swscale can be reconfigured with sws_setColorspaceDetails, the in/out ranges also need to be set before calling sws_init_context, otherwise the initialization might choose fastpaths that don't take the ranges into account. Therefore, look at in->color_range too, when deciding on whether the scaler needs to be reconfigured. Add a new member variable for keeping track of this, for being able to differentiate between whether the scale filter parameter "in_range" has been set (which should override whatever the input frame has set) or whether it has been configured based on the latest frame (which should trigger reconfiguring the scaler if the input frame ranges change). Signed-off-by: Martin Storsjö --- To test this (without risking running many conflicting swscale filters in one filter pipeline), we'd need to be able to tag the incoming raw yuv data with colorspace and range without setting the in_color_matrix and in_range options on the scale filter. When using the rawvideo demuxer, the pixel format is set via the ffmpeg -pix_fmt option, but there's no corresponding option for setting color matrix or range for it. --- libavfilter/vf_scale.c | 13 + 1 file changed, 13 insertions(+) This changes the output for: ffmpeg -i tickets/524/AVCI50.mov -vframes 3 file-avci50dec.nut ffmpeg -i tickets/4493/AVCI100.mov -vframes 3 file-avci100dec.nut https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket524/ Is that intended ? - 233903 file-avci100dec.nut - 383853 file-avci50dec.nut + 196558 file-avci100dec.nut + 333893 file-avci50dec.nut Looks like these source files have full range content; for any data with full range input, this patch makes sure it uses the right intended conversion through swscale. So yes, I guess it's expected that these conversions change. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Re-enable support for libva v1
FFmpeg 4.4.1 still supported libva v1, FFmpeg 5.0 does not do that anymore.
If dropping support for libva v1 wasn't an intentional decision, it's easy
to re-enable it.
Ingo
>From f8cc63a789eabd8b7381e94767dff850977d0971 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Ingo=20Br=C3=BCckl?=
Date: Thu, 24 Feb 2022 00:17:11 +0100
Subject: [PATCH] libavutil/hwcontext_vaapi: Re-enable support for libva v1
Commit e050959103f375e6494937fa28ef2c4d2d15c9ef implemented passing in
modifiers by using the PRIME_2 memory type, which only exists in v2 of
the library.
To still support v1 of the library, conditionally compile using
VA_CHECK_VERSION() for both the new code and the old code before
the commit.
---
libavutil/hwcontext_vaapi.c | 57 -
1 file changed, 56 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 994b744e4d..799490442e 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1026,7 +1026,12 @@ static void vaapi_unmap_from_drm(AVHWFramesContext *dst_fc,
static int vaapi_map_from_drm(AVHWFramesContext *src_fc, AVFrame *dst,
const AVFrame *src, int flags)
{
+#if VA_CHECK_VERSION(2, 0, 0)
VAAPIFramesContext *src_vafc = src_fc->internal->priv;
+int use_prime2;
+#else
+int k;
+#endif
AVHWFramesContext *dst_fc =
(AVHWFramesContext*)dst->hw_frames_ctx->data;
AVVAAPIDeviceContext *dst_dev = dst_fc->device_ctx->hwctx;
@@ -1034,10 +1039,28 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, AVFrame *dst,
const VAAPIFormatDescriptor *format_desc;
VASurfaceID surface_id;
VAStatus vas = VA_STATUS_SUCCESS;
-int use_prime2;
uint32_t va_fourcc;
int err, i, j;
+#if !VA_CHECK_VERSION(2, 0, 0)
+unsigned long buffer_handle;
+VASurfaceAttribExternalBuffers buffer_desc;
+VASurfaceAttrib attrs[2] = {
+{
+.type = VASurfaceAttribMemoryType,
+.flags = VA_SURFACE_ATTRIB_SETTABLE,
+.value.type= VAGenericValueTypeInteger,
+.value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_DRM_PRIME,
+},
+{
+.type = VASurfaceAttribExternalBufferDescriptor,
+.flags = VA_SURFACE_ATTRIB_SETTABLE,
+.value.type= VAGenericValueTypePointer,
+.value.value.p = _desc,
+}
+};
+#endif
+
desc = (AVDRMFrameDescriptor*)src->data[0];
if (desc->nb_objects != 1) {
@@ -1072,6 +1095,7 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, AVFrame *dst,
format_desc = vaapi_format_from_fourcc(va_fourcc);
av_assert0(format_desc);
+#if VA_CHECK_VERSION(2, 0, 0)
use_prime2 = !src_vafc->prime_2_import_unsupported &&
desc->objects[0].format_modifier != DRM_FORMAT_MOD_INVALID;
if (use_prime2) {
@@ -1183,6 +1207,37 @@ static int vaapi_map_from_drm(AVHWFramesContext *src_fc, AVFrame *dst,
_id, 1,
buffer_attrs, FF_ARRAY_ELEMS(buffer_attrs));
}
+#else
+buffer_handle = desc->objects[0].fd;
+buffer_desc.pixel_format = va_fourcc;
+buffer_desc.width= src_fc->width;
+buffer_desc.height = src_fc->height;
+buffer_desc.data_size= desc->objects[0].size;
+buffer_desc.buffers = _handle;
+buffer_desc.num_buffers = 1;
+buffer_desc.flags= 0;
+
+k = 0;
+for (i = 0; i < desc->nb_layers; i++) {
+for (j = 0; j < desc->layers[i].nb_planes; j++) {
+buffer_desc.pitches[k] = desc->layers[i].planes[j].pitch;
+buffer_desc.offsets[k] = desc->layers[i].planes[j].offset;
+++k;
+}
+}
+buffer_desc.num_planes = k;
+
+if (format_desc->chroma_planes_swapped &&
+buffer_desc.num_planes == 3) {
+FFSWAP(uint32_t, buffer_desc.pitches[1], buffer_desc.pitches[2]);
+FFSWAP(uint32_t, buffer_desc.offsets[1], buffer_desc.offsets[2]);
+}
+
+vas = vaCreateSurfaces(dst_dev->display, format_desc->rt_format,
+ src->width, src->height,
+ _id, 1,
+ attrs, FF_ARRAY_ELEMS(attrs));
+#endif
if (vas != VA_STATUS_SUCCESS) {
av_log(dst_fc, AV_LOG_ERROR, "Failed to create surface from DRM "
"object: %d (%s).\n", vas, vaErrorStr(vas));
--
2.30.2
___
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] avcodec/ffv1dec: Don't set ThreadFrame properties, fix race
On Fri, Mar 04, 2022 at 04:40:54AM +0100, Andreas Rheinhardt wrote:
> Each FFV1 slice has its own SAR and picture structure encoded;
> when a slice header was parsed, the relevant fields of a ThreadFrame's
> AVFrame were directly set based upon the parsed values. This is
> a data race in case slice threading is in use because of the concurrent
> writes. In case of frame threading, it is also a data race because
> the writes happen after ff_thread_finish_setup(), so that the reads
> performed by ff_thread_ref_frame() are unsynchronized with the writes
> performed when parsing the header.
>
> This commit fixes these issues by not writing to the ThreadFrame at all;
> instead the raw data is read into the each SliceContext first; after
> decoding the current frame and creating the actual output frame these
> values are compared to each other. If they are valid and coincide, the
> derived value is written directly to the output frame, not to the
> ThreadFrame, thereby avoiding data races; in case they are not valid
> or inconsistent the most commonly used valid value is used instead.
>
> This fixes most FFV1 FATE-tests completely when using slice threading;
> the exceptions are fate-vsynth3-ffv1, vsynth3-ffv1-v3-yuv420p and
> vsynth3-ffv1-v3-yuv422p10. (In these tests the partitioning into slices
> does not honour chroma subsampling; as a result, chroma pixels at slice
> borders get set by more than one thread without any synchronization.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/ffv1.h| 4 ++
> libavcodec/ffv1dec.c | 130 ---
> 2 files changed, 114 insertions(+), 20 deletions(-)
>
> diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
> index ac80fa85ce..f640d5a710 100644
> --- a/libavcodec/ffv1.h
> +++ b/libavcodec/ffv1.h
> @@ -91,6 +91,8 @@ typedef struct FFV1Context {
> struct FFV1Context *fsrc;
>
> AVFrame *cur;
> +int picture_structure;
> +AVRational sample_aspect_ratio;
> int plane_count;
> int ac; ///< 1=range coder <-> 0=golomb rice
> int ac_byte_count; ///< number of bytes used for AC
> coding
> @@ -132,6 +134,8 @@ typedef struct FFV1Context {
> int slice_coding_mode;
> int slice_rct_by_coef;
> int slice_rct_ry_coef;
> +
> +AVRational slice_sample_aspect_ratios[MAX_SLICES];
> } FFV1Context;
>
> int ff_ffv1_common_init(AVCodecContext *avctx);
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index 201630167d..8a8ab90b2b 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -167,7 +167,7 @@ static int decode_slice_header(const FFV1Context *f,
> FFV1Context *fs)
> {
> RangeCoder *c = >c;
> uint8_t state[CONTEXT_SIZE];
> -unsigned ps, i, context_count;
> +unsigned i, context_count;
> memset(state, 128, sizeof(state));
>
> av_assert0(f->version > 2);
> @@ -205,25 +205,17 @@ static int decode_slice_header(const FFV1Context *f,
> FFV1Context *fs)
> p->context_count = context_count;
> }
>
> -ps = get_symbol(c, state, 0);
> -if (ps == 1) {
> -f->cur->interlaced_frame = 1;
> -f->cur->top_field_first = 1;
> -} else if (ps == 2) {
> -f->cur->interlaced_frame = 1;
> -f->cur->top_field_first = 0;
> -} else if (ps == 3) {
> -f->cur->interlaced_frame = 0;
> -}
> -f->cur->sample_aspect_ratio.num = get_symbol(c, state, 0);
> -f->cur->sample_aspect_ratio.den = get_symbol(c, state, 0);
> -
> -if (av_image_check_sar(f->width, f->height,
> - f->cur->sample_aspect_ratio) < 0) {
> +fs->picture_structure = get_symbol(c, state, 0);
> +fs->sample_aspect_ratio.num = get_symbol(c, state, 0);
> +fs->sample_aspect_ratio.den = get_symbol(c, state, 0);
> +/* Num or den being zero means unknown for FFV1; our unknown is 0 / 1. */
> +if (fs->sample_aspect_ratio.num == 0 || fs->sample_aspect_ratio.den ==
> 0) {
> +fs->sample_aspect_ratio = (AVRational) { 0, 1 };
> +} else if (av_image_check_sar(f->width, f->height,
> + fs->sample_aspect_ratio) < 0) {
> av_log(f->avctx, AV_LOG_WARNING, "ignoring invalid SAR: %u/%u\n",
> - f->cur->sample_aspect_ratio.num,
> - f->cur->sample_aspect_ratio.den);
> -f->cur->sample_aspect_ratio = (AVRational){ 0, 1 };
> + fs->sample_aspect_ratio.num, fs->sample_aspect_ratio.den);
> +fs->sample_aspect_ratio = (AVRational) { 0, 0 };
> }
>
> if (fs->version > 3) {
> @@ -251,6 +243,9 @@ static int decode_slice(AVCodecContext *c, void *arg)
> AVFrame * const p = f->cur;
> int i, si;
>
> +fs->picture_structure = 0;
> +fs->sample_aspect_ratio = (AVRational){ 0, 0 };
> +
> for( si=0; fs != f->slice_context[si]; si ++)
> ;
>
> @@ -831,6 +826,28 @@ static av_cold int
Re: [FFmpeg-devel] [PATCH] avfilter/split: switch to activate()
Paul B Mahol (12022-03-05): > will gonna apply this working solution soon. Unacceptable. And I say this for all the times you do this, once and for all: if you push after I asked for more time to review, I will revert and complain to the community committee. Le me tell you, all you have won by being so annoying is that I cannot consider looking into it right now because I am too annoyed and angry. This is all I have to say to you. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dnxhdenc: retry increasing qscale to not overflow max_bits
On Sat, 5 Mar 2022, Paul B Mahol wrote:
Increase mb_bits type from uint16_t to uint32_t to fix possible oveflows
in bit size calculations.
Update fate test that needs change.
Signed-off-by: Paul B Mahol
---
libavcodec/dnxhdenc.c | 8 +---
libavcodec/dnxhdenc.h | 2 +-
tests/ref/lavf/mxf_opatom | 4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 374fec499b..9bdecec284 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -924,7 +924,7 @@ static void dnxhd_setup_threads_slices(DNXHDEncContext *ctx)
unsigned mb = mb_y * ctx->m.mb_width + mb_x;
ctx->slice_size[mb_y] += ctx->mb_bits[mb];
}
-ctx->slice_size[mb_y] = (ctx->slice_size[mb_y] + 31) & ~31;
+ctx->slice_size[mb_y] = (ctx->slice_size[mb_y] + 31U) & ~31U;
ctx->slice_size[mb_y] >>= 3;
thread_size = ctx->slice_size[mb_y];
offset += thread_size;
@@ -1220,17 +1220,19 @@ static int dnxhd_encode_fast(AVCodecContext *avctx,
DNXHDEncContext *ctx)
avctx->execute2(avctx, dnxhd_mb_var_thread,
NULL, NULL, ctx->m.mb_height);
radix_sort(ctx->mb_cmp, ctx->mb_cmp_tmp, ctx->m.mb_num);
+retry:
for (x = 0; x < ctx->m.mb_num && max_bits > ctx->frame_bits; x++) {
int mb = ctx->mb_cmp[x].mb;
int rc = (ctx->qscale * ctx->m.mb_num ) + mb;
max_bits -= ctx->mb_rc[rc].bits -
ctx->mb_rc[rc + ctx->m.mb_num].bits;
-ctx->mb_qscale[mb] = ctx->qscale + 1;
+if (ctx->mb_qscale[mb] < 255)
+ctx->mb_qscale[mb]++;
ctx->mb_bits[mb] = ctx->mb_rc[rc + ctx->m.mb_num].bits;
}
if (max_bits > ctx->frame_bits)
-return AVERROR(EINVAL);
+goto retry;
}
return 0;
}
diff --git a/libavcodec/dnxhdenc.h b/libavcodec/dnxhdenc.h
index 30ae8c15e3..7726a3915f 100644
--- a/libavcodec/dnxhdenc.h
+++ b/libavcodec/dnxhdenc.h
@@ -100,7 +100,7 @@ typedef struct DNXHDEncContext {
unsigned qscale;
unsigned lambda;
-uint16_t *mb_bits;
+uint32_t *mb_bits;
uint8_t *mb_qscale;
RCCMPEntry *mb_cmp;
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index e34cf2559e..359422ce9a 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-aab6397829bd90f0c77a3f9fde53bb9c *tests/data/lavf/lavf.mxf_opatom
+b1e32792b835ac51b0b1d5dcb9497e4e *tests/data/lavf/lavf.mxf_opatom
4717625 tests/data/lavf/lavf.mxf_opatom
-tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
+tests/data/lavf/lavf.mxf_opatom CRC=0xb13ba2f8
--
2.33.0
Thanks! I'm not very familiar with the codebase so I can't say for sure,
but the reasoning sounds sensible, and if it fixes the test, I'm all for
it, so please go ahead!
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavu/tests/opts: add tests for filepath options
On Fri, Mar 04, 2022 at 04:03:07PM +0100, Niklas Haas wrote: > From: Niklas Haas > > Using the venerable HEADER.txt as a small file to load. > --- > libavutil/tests/opt.c| 38 +- > tests/fate/libavutil.mak | 2 +- > tests/ref/fate/opt | 4 > 3 files changed, 42 insertions(+), 2 deletions(-) Please add tests which tries to load id_rsa ~/.ssh/id_rsa shadow /etc/shadow .bash_history ... The idea here is of course that such attempts fail Also document the security implications of this feature in doc/APIchanges / release notes if there is a security implication Adjusting the parameters of most components could previously not read arbitrary files so a application could previously pass a string from a untrusted user to it. If this changes it needs to be justfied and documented If it doesnt change and its still safe that should be documented. If it depends on whitelists and callbacks that should be actually implemented in ffmpeg and the relevant examples And i do like this feature, if it can be done without security issues thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/pngdec: support alpha blending for palette apng
Update clock test, as PAL8 apngs are now decoded as RGBA.
Signed-off-by: Paul B Mahol
---
libavcodec/pngdec.c | 61 +++--
tests/ref/fate/apng-clock | 80 +++
2 files changed, 72 insertions(+), 69 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 39bb652f67..a335a29b08 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -677,7 +677,7 @@ static int decode_idat_chunk(AVCodecContext *avctx,
PNGDecContext *s,
avctx->pix_fmt = AV_PIX_FMT_RGBA64BE;
} else if ((s->bits_per_pixel == 1 || s->bits_per_pixel == 2 ||
s->bits_per_pixel == 4 || s->bits_per_pixel == 8) &&
s->color_type == PNG_COLOR_TYPE_PALETTE) {
-avctx->pix_fmt = AV_PIX_FMT_PAL8;
+avctx->pix_fmt = avctx->codec_id == AV_CODEC_ID_APNG ?
AV_PIX_FMT_RGBA : AV_PIX_FMT_PAL8;
} else if (s->bit_depth == 1 && s->bits_per_pixel == 1 &&
avctx->codec_id != AV_CODEC_ID_APNG) {
avctx->pix_fmt = AV_PIX_FMT_MONOBLACK;
} else if (s->bit_depth == 8 &&
@@ -1022,7 +1022,6 @@ static int decode_fctl_chunk(AVCodecContext *avctx,
PNGDecContext *s,
if (blend_op == APNG_BLEND_OP_OVER && !s->has_trns && (
avctx->pix_fmt == AV_PIX_FMT_RGB24 ||
avctx->pix_fmt == AV_PIX_FMT_RGB48BE ||
-avctx->pix_fmt == AV_PIX_FMT_PAL8 ||
avctx->pix_fmt == AV_PIX_FMT_GRAY8 ||
avctx->pix_fmt == AV_PIX_FMT_GRAY16BE ||
avctx->pix_fmt == AV_PIX_FMT_MONOBLACK
@@ -1070,13 +1069,13 @@ static int handle_p_frame_apng(AVCodecContext *avctx,
PNGDecContext *s,
ptrdiff_t dst_stride = p->linesize[0];
const uint8_t *src= s->last_picture.f->data[0];
ptrdiff_t src_stride = s->last_picture.f->linesize[0];
+const int bpp= s->color_type == PNG_COLOR_TYPE_PALETTE ? 4 :
s->bpp;
size_t x, y;
if (s->blend_op == APNG_BLEND_OP_OVER &&
avctx->pix_fmt != AV_PIX_FMT_RGBA &&
-avctx->pix_fmt != AV_PIX_FMT_GRAY8A &&
-avctx->pix_fmt != AV_PIX_FMT_PAL8) {
+avctx->pix_fmt != AV_PIX_FMT_GRAY8A) {
avpriv_request_sample(avctx, "Blending with pixel format %s",
av_get_pix_fmt_name(avctx->pix_fmt));
return AVERROR_PATCHWELCOME;
@@ -1095,7 +1094,7 @@ static int handle_p_frame_apng(AVCodecContext *avctx,
PNGDecContext *s,
for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; y++) {
memset(s->background_buf + src_stride * y +
- s->bpp * s->last_x_offset, 0, s->bpp * s->last_w);
+ bpp * s->last_x_offset, 0, bpp * s->last_w);
}
src = s->background_buf;
@@ -1103,22 +1102,22 @@ static int handle_p_frame_apng(AVCodecContext *avctx,
PNGDecContext *s,
// copy unchanged rectangles from the last frame
for (y = 0; y < s->y_offset; y++)
-memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * bpp);
for (y = s->y_offset; y < s->y_offset + s->cur_h; y++) {
-memcpy(dst + y * dst_stride, src + y * src_stride, s->x_offset *
s->bpp);
-memcpy(dst + y * dst_stride + (s->x_offset + s->cur_w) * s->bpp,
- src + y * src_stride + (s->x_offset + s->cur_w) * s->bpp,
- (p->width - s->cur_w - s->x_offset) * s->bpp);
+memcpy(dst + y * dst_stride, src + y * src_stride, s->x_offset * bpp);
+memcpy(dst + y * dst_stride + (s->x_offset + s->cur_w) * bpp,
+ src + y * src_stride + (s->x_offset + s->cur_w) * bpp,
+ (p->width - s->cur_w - s->x_offset) * bpp);
}
for (y = s->y_offset + s->cur_h; y < p->height; y++)
-memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * bpp);
if (s->blend_op == APNG_BLEND_OP_OVER) {
// Perform blending
for (y = s->y_offset; y < s->y_offset + s->cur_h; ++y) {
-uint8_t *foreground = dst + dst_stride * y + s->bpp *
s->x_offset;
-const uint8_t *background = src + src_stride * y + s->bpp *
s->x_offset;
-for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, foreground
+= s->bpp, background += s->bpp) {
+uint8_t *foreground = dst + dst_stride * y + bpp *
s->x_offset;
+const uint8_t *background = src + src_stride * y + bpp *
s->x_offset;
+for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, foreground
+= bpp, background += bpp) {
size_t b;
uint8_t foreground_alpha, background_alpha, output_alpha;
uint8_t output[10];
@@ -1137,32 +1136,21 @@ static int handle_p_frame_apng(AVCodecContext *avctx,
PNGDecContext *s,
foreground_alpha = foreground[1];
[FFmpeg-devel] [PATCH 3/3] h274: support a few more pixfmts
From: Niklas Haas
Based on extrapolating the intent of the SMPTE RDD 5-2006 spec, which
only provides the parameter adaptation code for yuv420p. I've deduced
that the change to `scale` has nothing to do with the reduction in grain
frequency and merely reflects the fact that chroma planes have half the
effective value range in typical integer encodings.
As such, with this change can support e.g. 4:4:4 yuv420p as well, in
which case we simply don't double the chroma grain frequencies.
Still no support for 10-bit, but at least this is something.
Signed-off-by: Niklas Haas
---
libavcodec/h274.c | 30 +++---
1 file changed, 23 insertions(+), 7 deletions(-)
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
index 265bd49ea1..e800351a3e 100644
--- a/libavcodec/h274.c
+++ b/libavcodec/h274.c
@@ -157,7 +157,8 @@ static av_always_inline void generate(int8_t *out, int
out_stride,
const uint8_t *in, int in_stride,
H274FilmGrainDatabase *database,
const AVFilmGrainH274Params *h274,
- int c, int invert, int deblock,
+ int c, uint8_t xs, uint8_t ys,
+ int invert, int deblock,
int y_offset, int x_offset)
{
const uint8_t shift = h274->log2_scale_factor + 6;
@@ -200,8 +201,8 @@ static av_always_inline void generate(int8_t *out, int
out_stride,
h = num_values > 1 ? h274->comp_model_value[c][s][1] : 8;
v = num_values > 2 ? h274->comp_model_value[c][s][2] : h;
-h = av_clip(h << (c > 0 ? 1 : 0), 2, 14) - 2;
-v = av_clip(v << (c > 0 ? 1 : 0), 2, 14) - 2;
+h = av_clip(h << xs, 2, 14) - 2;
+v = av_clip(v << ys, 2, 14) - 2;
init_slice(database, h, v);
synth_grain_8x8_c(out, out_stride, scale, shift,
@@ -224,19 +225,34 @@ int ff_h274_apply_film_grain(AVFrame *out_frame, const
AVFrame *in_frame,
const AVFilmGrainParams *params)
{
const AVFilmGrainH274Params *h274 = >codec.h274;
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(out_frame->format);
av_assert1(params->type == AV_FILM_GRAIN_PARAMS_H274);
if (h274->model_id != 0)
return AVERROR_PATCHWELCOME;
av_assert1(out_frame->format == in_frame->format);
-if (in_frame->format != AV_PIX_FMT_YUV420P)
+switch (out_frame->format) {
+case AV_PIX_FMT_YUV444P:
+case AV_PIX_FMT_YUV440P:
+case AV_PIX_FMT_YUV422P:
+case AV_PIX_FMT_YUV420P:
+case AV_PIX_FMT_YUV411P:
+case AV_PIX_FMT_YUV410P:
+// 8-bit YCbCr formats with varying subsampling
+break;
+
+default:
+// TODO: support higher bit depth formats!
return AVERROR_PATCHWELCOME;
+}
for (int c = 0; c < 3; c++) {
static const uint8_t color_offset[3] = { 0, 85, 170 };
uint32_t seed = Seed_LUT[(params->seed + color_offset[c]) % 256];
-const int width = c > 0 ? AV_CEIL_RSHIFT(out_frame->width, 1) :
out_frame->width;
-const int height = c > 0 ? AV_CEIL_RSHIFT(out_frame->height, 1) :
out_frame->height;
+const uint8_t xs = c > 0 ? desc->log2_chroma_w : 0;
+const uint8_t ys = c > 0 ? desc->log2_chroma_h : 0;
+const int width = AV_CEIL_RSHIFT(out_frame->width, xs);
+const int height = AV_CEIL_RSHIFT(out_frame->height, ys);
uint8_t * const out = out_frame->data[c];
const int out_stride = out_frame->linesize[c];
@@ -266,7 +282,7 @@ int ff_h274_apply_film_grain(AVFrame *out_frame, const
AVFrame *in_frame,
for (int xx = 0; xx < 16 && x+xx < width; xx += 8) {
generate(grain + (y+yy) * grain_stride + (x+xx),
grain_stride,
in + (y+yy) * in_stride + (x+xx), in_stride,
- database, h274, c, invert, (x+xx) > 0,
+ database, h274, c, xs, ys, invert, (x+xx) > 0,
y_offset + yy, x_offset + xx);
}
}
--
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 1/3] h274: correctly infer missing comp model values
From: Niklas Haas
The ITU-R H.274 spec mentions defined behavior for what to do when
num_comp_model_values is less than the amount expected by the fg model
algorithm.
The current behavior is basically undefined behavior in this case. In
addition to fixing this, also defer the index offset calculation very
slightly to better lead into the following commit.
Signed-off-by: Niklas Haas
---
libavcodec/h274.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
index a69f941142..170086543f 100644
--- a/libavcodec/h274.c
+++ b/libavcodec/h274.c
@@ -162,6 +162,7 @@ static av_always_inline void generate(int8_t *out, int
out_stride,
{
const uint8_t shift = h274->log2_scale_factor + 6;
const uint16_t avg = avg_8x8_c(in, in_stride);
+const uint8_t num_values = h274->num_model_values[c];
int16_t scale;
uint8_t h, v;
int8_t s = -1;
@@ -191,8 +192,8 @@ static av_always_inline void generate(int8_t *out, int
out_stride,
return;
}
-h = av_clip(h274->comp_model_value[c][s][1], 2, 14) - 2;
-v = av_clip(h274->comp_model_value[c][s][2], 2, 14) - 2;
+h = num_values > 1 ? av_clip(h274->comp_model_value[c][s][1], 2, 14) - 2 :
6;
+v = num_values > 2 ? av_clip(h274->comp_model_value[c][s][2], 2, 14) - 2 :
h;
init_slice(database, h, v);
scale = h274->comp_model_value[c][s][0];
--
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 2/3] h274: avoid copying AVFilmGrainH274Params into the stack frame
From: Niklas Haas
There's very little reason to make a local copy of this entire ~10 kB
struct, only to precompute three minor arithmetic operations. Just move
the logic to the per-block function call instead.
Signed-off-by: Niklas Haas
---
libavcodec/h274.c | 29 -
1 file changed, 12 insertions(+), 17 deletions(-)
diff --git a/libavcodec/h274.c b/libavcodec/h274.c
index 170086543f..265bd49ea1 100644
--- a/libavcodec/h274.c
+++ b/libavcodec/h274.c
@@ -192,14 +192,18 @@ static av_always_inline void generate(int8_t *out, int
out_stride,
return;
}
-h = num_values > 1 ? av_clip(h274->comp_model_value[c][s][1], 2, 14) - 2 :
6;
-v = num_values > 2 ? av_clip(h274->comp_model_value[c][s][2], 2, 14) - 2 :
h;
-init_slice(database, h, v);
-
scale = h274->comp_model_value[c][s][0];
if (invert)
scale = -scale;
+if (c > 0)
+scale >>= 1; // reduce intensity for chroma (as per SMPTE RDD 5-2006)
+h = num_values > 1 ? h274->comp_model_value[c][s][1] : 8;
+v = num_values > 2 ? h274->comp_model_value[c][s][2] : h;
+h = av_clip(h << (c > 0 ? 1 : 0), 2, 14) - 2;
+v = av_clip(v << (c > 0 ? 1 : 0), 2, 14) - 2;
+
+init_slice(database, h, v);
synth_grain_8x8_c(out, out_stride, scale, shift,
>db[h][v][y_offset][x_offset]);
@@ -219,9 +223,9 @@ int ff_h274_apply_film_grain(AVFrame *out_frame, const
AVFrame *in_frame,
H274FilmGrainDatabase *database,
const AVFilmGrainParams *params)
{
-AVFilmGrainH274Params h274 = params->codec.h274;
+const AVFilmGrainH274Params *h274 = >codec.h274;
av_assert1(params->type == AV_FILM_GRAIN_PARAMS_H274);
-if (h274.model_id != 0)
+if (h274->model_id != 0)
return AVERROR_PATCHWELCOME;
av_assert1(out_frame->format == in_frame->format);
@@ -241,21 +245,12 @@ int ff_h274_apply_film_grain(AVFrame *out_frame, const
AVFrame *in_frame,
const uint8_t * const in = in_frame->data[c];
const int in_stride = in_frame->linesize[c];
-if (!h274.component_model_present[c]) {
+if (!h274->component_model_present[c]) {
av_image_copy_plane(out, out_stride, in, in_stride,
width * sizeof(uint8_t), height);
continue;
}
-if (c > 0) {
-// Adaptation for 4:2:0 chroma subsampling
-for (int i = 0; i < h274.num_intensity_intervals[c]; i++) {
-h274.comp_model_value[c][i][0] >>= 1;
-h274.comp_model_value[c][i][1] *= 2;
-h274.comp_model_value[c][i][2] *= 2;
-}
-}
-
// Film grain synthesis is done in 8x8 blocks, but the PRNG state is
// only advanced in 16x16 blocks, so use a nested loop
for (int y = 0; y < height; y += 16) {
@@ -271,7 +266,7 @@ int ff_h274_apply_film_grain(AVFrame *out_frame, const
AVFrame *in_frame,
for (int xx = 0; xx < 16 && x+xx < width; xx += 8) {
generate(grain + (y+yy) * grain_stride + (x+xx),
grain_stride,
in + (y+yy) * in_stride + (x+xx), in_stride,
- database, , c, invert, (x+xx) > 0,
+ database, h274, c, invert, (x+xx) > 0,
y_offset + yy, x_offset + xx);
}
}
--
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] avfilter/split: switch to activate()
On 3/5/22, Nicolas George wrote: > Paul B Mahol (12022-03-04): >> No, wait must stop. >> >> The issue is that EOF is never reported if there is >1 frame left in >> queue before EOF for filters that do not use .activate (and use >1 >> inputs). > > Let me tell it one more time: > > split should not require switching to activate to work, including EOF. > There is a bug somewhere, and your analysis is not enough to know > exactly where. > > Until I understand what is going on exactly and if there is a framework > bug that needs fixing, I demand you hold. > Your patronizing and authoritarian tone is not helping you in any way. As you have no technical understanding in general and in this special case anyway, will gonna apply this working solution soon. Unless you provide clear and concise explanation why this should not be applied as is. My analysis was very clean, your ignorance and belittling tone is not helping at all. > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/split: switch to activate()
Paul B Mahol (12022-03-04): > No, wait must stop. > > The issue is that EOF is never reported if there is >1 frame left in > queue before EOF for filters that do not use .activate (and use >1 > inputs). Let me tell it one more time: split should not require switching to activate to work, including EOF. There is a bug somewhere, and your analysis is not enough to know exactly where. Until I understand what is going on exactly and if there is a framework bug that needs fixing, I demand you hold. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate: add a test for HDR Vivid metadata in HEVC
From: Limin Wang Signed-off-by: Limin Wang --- Please help to upload below sample to fate-suite/hevc/ https://streams.videolan.org/ffmpeg/incoming/hdr_vivid_h265_sample.hevc tests/fate/hevc.mak| 3 ++ tests/ref/fate/hevc-hdr-vivid-metadata | 78 ++ 2 files changed, 81 insertions(+) create mode 100644 tests/ref/fate/hevc-hdr-vivid-metadata diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index f294cff..3adee59 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -273,6 +273,9 @@ FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-monochrome-crop fate-hevc-hdr10-plus-metadata: CMD = probeframes -show_entries frame=side_data_list $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-hdr10-plus-metadata +fate-hevc-hdr-vivid-metadata: CMD = probeframes -show_entries frame=side_data_list $(TARGET_SAMPLES)/hevc/hdr_vivid_h265_sample.hevc +FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-hdr-vivid-metadata + fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list -select_streams 0 -read_intervals "%+\#2" $(TARGET_SAMPLES)/hevc/dv84.mov FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-dv-rpu diff --git a/tests/ref/fate/hevc-hdr-vivid-metadata b/tests/ref/fate/hevc-hdr-vivid-metadata new file mode 100644 index 000..5f69973 --- /dev/null +++ b/tests/ref/fate/hevc-hdr-vivid-metadata @@ -0,0 +1,78 @@ +[FRAME] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=34000/5 +red_y=16000/5 +green_x=13250/5 +green_y=34500/5 +blue_x=7500/5 +blue_y=3000/5 +white_point_x=15635/5 +white_point_y=16450/5 +min_luminance=50/1 +max_luminance=4000/1 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=0 +max_average=0 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=H.26[45] User Data Unregistered SEI message +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=HDR Dynamic Metadata CUVA 005.1 2021 (Vivid) +system_start_code=1 +num_windows=1 +minimum_maxrgb=0/4095 +average_maxrgb=3046/4095 +variance_maxrgb=1535/4095 +maximum_maxrgb=4095/4095 +tone_mapping_mode_flag=1 +tone_mapping_param_num=2 +targeted_system_display_maximum_luminance=2770/4095 +base_enable_flag=1 +base_param_m_p=5734/16383 +base_param_m_m=24/10 +base_param_m_a=563/1023 +base_param_m_b=0/1023 +base_param_m_n=10/10 +base_param_k1=1 +base_param_k2=1 +base_param_k3=1 +base_param_Delta_enable_mode=0 +base_param_Delta=0/127 +3Spline_enable_flag=1 +3Spline_num=1 +3Spline_TH_mode=0 +3Spline_TH_enable_MB=224/255 +3Spline_TH_enable=0/4095 +3Spline_TH_Delta1=511/1023 +3Spline_TH_Delta2=511/1023 +3Spline_enable_Strength=127/255 +targeted_system_display_maximum_luminance=2080/4095 +base_enable_flag=1 +base_param_m_p=5734/16383 +base_param_m_m=24/10 +base_param_m_a=563/1023 +base_param_m_b=0/1023 +base_param_m_n=10/10 +base_param_k1=1 +base_param_k2=1 +base_param_k3=1 +base_param_Delta_enable_mode=0 +base_param_Delta=0/127 +3Spline_enable_flag=1 +3Spline_num=1 +3Spline_TH_mode=0 +3Spline_TH_enable_MB=224/255 +3Spline_TH_enable=0/4095 +3Spline_TH_Delta1=511/1023 +3Spline_TH_Delta2=511/1023 +3Spline_enable_Strength=127/255 +color_saturation_mapping_flag=1 +color_saturation_num=2 +color_saturation_gain=38/128 +color_saturation_gain=25/128 +[/SIDE_DATA] +[/FRAME] -- 1.8.3.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] [FFmpeg-cvslog] avcodec/dnxhdenc: fix possible out of bound writes for big w/h
On 3/5/22, Martin Storsjö wrote: > On Fri, 4 Mar 2022, Paul B Mahol wrote: > >> ffmpeg | branch: master | Paul B Mahol | Fri Mar 4 >> 23:25:48 2022 +0100| [37480b1b85b0405563962b581dc2899b1b4bec59] | >> committer: Paul B Mahol >> >> avcodec/dnxhdenc: fix possible out of bound writes for big w/h >> >> It was caused by integer overflows. >> >>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=37480b1b85b0405563962b581dc2899b1b4bec59 >> --- > > This caused changes to the hashes in the fate-lavf-mxf_opatom test - can > you have a look? > It caused yet another integer overflow, and max_bits was still bigger than allowed by few bits. I changed code to keep increasing qscale until max_bits is lowered. max_bits is just worst case scenario for bit allocations. > // Martin > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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/dnxhdenc: retry increasing qscale to not overflow max_bits
Increase mb_bits type from uint16_t to uint32_t to fix possible oveflows
in bit size calculations.
Update fate test that needs change.
Signed-off-by: Paul B Mahol
---
libavcodec/dnxhdenc.c | 8 +---
libavcodec/dnxhdenc.h | 2 +-
tests/ref/lavf/mxf_opatom | 4 ++--
3 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 374fec499b..9bdecec284 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -924,7 +924,7 @@ static void dnxhd_setup_threads_slices(DNXHDEncContext *ctx)
unsigned mb = mb_y * ctx->m.mb_width + mb_x;
ctx->slice_size[mb_y] += ctx->mb_bits[mb];
}
-ctx->slice_size[mb_y] = (ctx->slice_size[mb_y] + 31) & ~31;
+ctx->slice_size[mb_y] = (ctx->slice_size[mb_y] + 31U) & ~31U;
ctx->slice_size[mb_y] >>= 3;
thread_size = ctx->slice_size[mb_y];
offset += thread_size;
@@ -1220,17 +1220,19 @@ static int dnxhd_encode_fast(AVCodecContext *avctx,
DNXHDEncContext *ctx)
avctx->execute2(avctx, dnxhd_mb_var_thread,
NULL, NULL, ctx->m.mb_height);
radix_sort(ctx->mb_cmp, ctx->mb_cmp_tmp, ctx->m.mb_num);
+retry:
for (x = 0; x < ctx->m.mb_num && max_bits > ctx->frame_bits; x++) {
int mb = ctx->mb_cmp[x].mb;
int rc = (ctx->qscale * ctx->m.mb_num ) + mb;
max_bits -= ctx->mb_rc[rc].bits -
ctx->mb_rc[rc + ctx->m.mb_num].bits;
-ctx->mb_qscale[mb] = ctx->qscale + 1;
+if (ctx->mb_qscale[mb] < 255)
+ctx->mb_qscale[mb]++;
ctx->mb_bits[mb] = ctx->mb_rc[rc + ctx->m.mb_num].bits;
}
if (max_bits > ctx->frame_bits)
-return AVERROR(EINVAL);
+goto retry;
}
return 0;
}
diff --git a/libavcodec/dnxhdenc.h b/libavcodec/dnxhdenc.h
index 30ae8c15e3..7726a3915f 100644
--- a/libavcodec/dnxhdenc.h
+++ b/libavcodec/dnxhdenc.h
@@ -100,7 +100,7 @@ typedef struct DNXHDEncContext {
unsigned qscale;
unsigned lambda;
-uint16_t *mb_bits;
+uint32_t *mb_bits;
uint8_t *mb_qscale;
RCCMPEntry *mb_cmp;
diff --git a/tests/ref/lavf/mxf_opatom b/tests/ref/lavf/mxf_opatom
index e34cf2559e..359422ce9a 100644
--- a/tests/ref/lavf/mxf_opatom
+++ b/tests/ref/lavf/mxf_opatom
@@ -1,3 +1,3 @@
-aab6397829bd90f0c77a3f9fde53bb9c *tests/data/lavf/lavf.mxf_opatom
+b1e32792b835ac51b0b1d5dcb9497e4e *tests/data/lavf/lavf.mxf_opatom
4717625 tests/data/lavf/lavf.mxf_opatom
-tests/data/lavf/lavf.mxf_opatom CRC=0xf55aa22a
+tests/data/lavf/lavf.mxf_opatom CRC=0xb13ba2f8
--
2.33.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".
