Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move the dpb logic from VAAPI to base layer

[Lynne via ffmpeg-devel]

On 12/06/2024 10:44, Wu, Tong1 wrote:

From: ffmpeg-devel  On Behalf Of Lynne
via ffmpeg-devel
Sent: Monday, June 10, 2024 10:01 AM
To: FFmpeg development discussions and patches 
Cc: Lynne 
Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode: move
the dpb logic from VAAPI to base layer

On 07/06/2024 18:48, Lynne wrote:

On 07/06/2024 17:22, Wu, Tong1 wrote:

From: ffmpeg-devel  On Behalf Of

Lynne

via ffmpeg-devel
Sent: Friday, June 7, 2024 11:10 PM
To: ffmpeg-devel@ffmpeg.org
Cc: Lynne 
Subject: Re: [FFmpeg-devel] [PATCH v13 06/15] avcodec/vaapi_encode:

move

the dpb logic from VAAPI to base layer

On 03/06/2024 11:18, tong1.wu-at-intel@ffmpeg.org wrote:

From: Tong Wu 

Move receive_packet function to base. This requires adding *alloc,
*issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
introduced as the base layer structure. The related parameters in
VAAPIEncodeContext are also extracted to HWBaseEncodeContext. Then

DPB

management logic can be fully extracted to base layer as-is.

Signed-off-by: Tong Wu 
---
    libavcodec/Makefile |   2 +-
    libavcodec/hw_base_encode.c | 594 
    libavcodec/hw_base_encode.h | 124 +
    libavcodec/vaapi_encode.c   | 793 +
---
    libavcodec/vaapi_encode.h   | 102 +---
    libavcodec/vaapi_encode_av1.c   |  35 +-
    libavcodec/vaapi_encode_h264.c  |  84 ++--
    libavcodec/vaapi_encode_h265.c  |  53 ++-
    libavcodec/vaapi_encode_mjpeg.c |  13 +-
    libavcodec/vaapi_encode_mpeg2.c |  33 +-
    libavcodec/vaapi_encode_vp8.c   |  18 +-
    libavcodec/vaapi_encode_vp9.c   |  24 +-
    12 files changed, 985 insertions(+), 890 deletions(-)
    create mode 100644 libavcodec/hw_base_encode.c


This patch doesn't apply,

error: sha1 information is lacking or useless (libavcodec/
hw_base_encode.c).
error: could not build fake ancestor

Could you resent the patchset or link me a repo so I can work with it?


https://github.com/intel-media-ci/ffmpeg/pull/689 This is the same as
v13 please have a try.


That worked, thanks.


I don't think the behaviour is correct when the encoding length is less
than the decode delay. In my old Vulkan code, I had this piece of code
in the initialization function:


if (!src) {
 ctx->end_of_stream = 1;
 /* Fix timestamps if we hit end-of-stream before the initial
  * decode delay has elapsed. */
 if (ctx->input_order < ctx->decode_delay)
 ctx->dts_pts_diff = ctx->pic_end->pts - ctx->first_pts;
 return AVERROR_EOF;
}


I think a flush function should be added, to be called by each encoder,
to make sure the timestamps remain correct.



For the current patch set, this piece is in hw_base_encode_send_frame and works 
well for vaapi and d3d12 except when the encoding length is equal to the decode 
delay, which I'll sent a fix later. Do you mean Vulkan cannot integrate into 
this part and we have to make a callback for it?


No, I was just curious. Fair enough, it can be implemented in a later patch.




Also, the D3D12VA structures need an FF prefix, e.g.
D3D12VAEncodeContext -> FFD3D12VAEncodeContext.


The current VAAPIEncodeContext has existed for a long time. Does it have any 
difference for D3D12VAEncodeContext? I mean both VAAPIEncodeContext and 
D3D12VAEncodeContext are parallel and only referenced in vaapi_encode_*.c 
(d3d12va_encode_*.c).

Thanks,
Tong


I'm finishing up on the Vulkan test implementation, I'll see to pushing 
this patch over the weekend.


OpenPGP_0xA2FEA5F03F034464.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital 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 v4] area changed: scdet filter

[Tobias Rapp]

On 13/06/2024 20:16, radu.taraib...@gmail.com wrote:


Update as discussed


The mode options are fine to me, will leave the implementation check and 
final push to Michael.


(Only if you update the patch anyway I'd suggest rewording the commit 
message to rephrase the "legacy" mode there, too, and maybe a more 
common patch title line like "avfilter/scdet: add improved detection 
modes". But no need to resend the patch for such cosmetics only.)


Regards, Tobias

___
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 v1] lavc/hevcdec: Put slice address checking after hwaccel decode slice

[fei . w . wang-at-intel . com]

From: Fei Wang 

Slice address tab only been updated in software decode slice data.

Fixes hwaccel decoding after d725c737fe2a19091b481d4d115fd939e0a674b2.

Signed-off-by: Fei Wang 
---
 libavcodec/hevc/hevcdec.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/hevc/hevcdec.c b/libavcodec/hevc/hevcdec.c
index 1d2e53afc3..39beb7e4dc 100644
--- a/libavcodec/hevc/hevcdec.c
+++ b/libavcodec/hevc/hevcdec.c
@@ -2770,15 +2770,6 @@ static int decode_slice_data(HEVCContext *s, const 
H2645NAL *nal, GetBitContext
 const HEVCPPS *pps = s->pps;
 int ret;
 
-if (s->sh.dependent_slice_segment_flag) {
-int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs];
-int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
-if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
-av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment missing\n");
-return AVERROR_INVALIDDATA;
-}
-}
-
 if (!s->sh.dependent_slice_segment_flag && s->sh.slice_type != 
HEVC_SLICE_I) {
 ret = ff_hevc_slice_rpl(s);
 if (ret < 0) {
@@ -2799,6 +2790,15 @@ static int decode_slice_data(HEVCContext *s, const 
H2645NAL *nal, GetBitContext
 return AVERROR_PATCHWELCOME;
 }
 
+if (s->sh.dependent_slice_segment_flag) {
+int ctb_addr_ts = pps->ctb_addr_rs_to_ts[s->sh.slice_ctb_addr_rs];
+int prev_rs = pps->ctb_addr_ts_to_rs[ctb_addr_ts - 1];
+if (s->tab_slice_address[prev_rs] != s->sh.slice_addr) {
+av_log(s->avctx, AV_LOG_ERROR, "Previous slice segment missing\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
 s->local_ctx[0].first_qp_group = !s->sh.dependent_slice_segment_flag;
 
 if (!pps->cu_qp_delta_enabled_flag)
-- 
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".

[FFmpeg-devel] [PATCH v2 1/2] configure: Alphabetical order for av1 codecs

[fei . w . wang-at-intel . com]

From: Fei Wang 

Signed-off-by: Fei Wang 
---
 configure | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/configure b/configure
index 06a72e4114..6d31698142 100755
--- a/configure
+++ b/configure
@@ -3321,12 +3321,18 @@ nvenc_deps_any="libdl LoadLibrary"
 
 aac_mf_encoder_deps="mediafoundation"
 ac3_mf_encoder_deps="mediafoundation"
+av1_amf_encoder_deps="amf"
 av1_cuvid_decoder_deps="cuvid CUVIDAV1PICPARAMS"
 av1_mediacodec_decoder_deps="mediacodec"
 av1_mediacodec_encoder_deps="mediacodec"
 av1_mediacodec_encoder_select="extract_extradata_bsf"
 av1_nvenc_encoder_deps="nvenc NV_ENC_PIC_PARAMS_AV1"
 av1_nvenc_encoder_select="atsc_a53"
+av1_qsv_decoder_select="qsvdec"
+av1_qsv_encoder_deps="libvpl"
+av1_qsv_encoder_select="qsvenc"
+av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
+av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
 h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m"
 h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m"
 h264_amf_encoder_deps="amf"
@@ -3415,12 +3421,6 @@ vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
 vp9_v4l2m2m_decoder_deps="v4l2_m2m vp9_v4l2_m2m"
-av1_qsv_decoder_select="qsvdec"
-av1_qsv_encoder_select="qsvenc"
-av1_qsv_encoder_deps="libvpl"
-av1_amf_encoder_deps="amf"
-av1_vaapi_encoder_deps="VAEncPictureParameterBufferAV1"
-av1_vaapi_encoder_select="cbs_av1 vaapi_encode"
 
 # parsers
 aac_parser_select="adts_header mpeg4audio"
-- 
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".

[FFmpeg-devel] [PATCH v2 2/2] lavc/qsvdec: Add VVC decoder

[fei . w . wang-at-intel . com]

From: Fei Wang 

Signed-off-by: Fei Wang 
---
 Changelog  | 1 +
 configure  | 1 +
 doc/decoders.texi  | 2 +-
 libavcodec/allcodecs.c | 1 +
 libavcodec/qsv.c   | 4 
 libavcodec/qsvdec.c| 7 ++-
 libavcodec/version.h   | 2 +-
 7 files changed, 15 insertions(+), 3 deletions(-)

diff --git a/Changelog b/Changelog
index 881b0e67a3..1fd1fce0c6 100644
--- a/Changelog
+++ b/Changelog
@@ -13,6 +13,7 @@ version :
 - VVC decoder compatible with DVB test content
 - xHE-AAC decoder
 - removed DEC Alpha DSP and support code
+- Intel QSV-accelerated VVC decoding
 
 
 version 7.0:
diff --git a/configure b/configure
index 6d31698142..d50f444141 100755
--- a/configure
+++ b/configure
@@ -3421,6 +3421,7 @@ vp9_vaapi_encoder_select="vaapi_encode"
 vp9_qsv_encoder_deps="libmfx MFX_CODEC_VP9"
 vp9_qsv_encoder_select="qsvenc"
 vp9_v4l2m2m_decoder_deps="v4l2_m2m vp9_v4l2_m2m"
+vvc_qsv_decoder_select="qsvdec"
 
 # parsers
 aac_parser_select="adts_header mpeg4audio"
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 293c82c2ba..2fcc761d2f 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -157,7 +157,7 @@ Force to use a specific number of threads
 @section QSV Decoders
 
 The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264, HEVC,
-JPEG/MJPEG, VP8, VP9, AV1).
+JPEG/MJPEG, VP8, VP9, AV1, VVC).
 
 @subsection Common Options
 
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index b102a8069e..a73b4e1673 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -885,6 +885,7 @@ extern const FFCodec ff_vp9_mediacodec_encoder;
 extern const FFCodec ff_vp9_qsv_decoder;
 extern const FFCodec ff_vp9_vaapi_encoder;
 extern const FFCodec ff_vp9_qsv_encoder;
+extern const FFCodec ff_vvc_qsv_decoder;
 
 // null codecs
 extern const FFCodec ff_vnull_decoder;
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 0c6fbd0dc0..221c1b24e5 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -73,6 +73,10 @@ int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id)
 case AV_CODEC_ID_AV1:
 return MFX_CODEC_AV1;
 #endif
+#if QSV_VERSION_ATLEAST(2, 11)
+case AV_CODEC_ID_VVC:
+return MFX_CODEC_VVC;
+#endif
 
 default:
 break;
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index f2cd6ae05c..9ad3439991 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -933,7 +933,8 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 frame->pict_type = 
ff_qsv_map_pictype(aframe.frame->dec_info.FrameType);
 
 if (avctx->codec_id == AV_CODEC_ID_H264 ||
-avctx->codec_id == AV_CODEC_ID_HEVC) {
+avctx->codec_id == AV_CODEC_ID_HEVC ||
+avctx->codec_id == AV_CODEC_ID_VVC) {
 if (aframe.frame->dec_info.FrameType & MFX_FRAMETYPE_IDR)
 frame->flags |= AV_FRAME_FLAG_KEY;
 else
@@ -1300,3 +1301,7 @@ DEFINE_QSV_DECODER(vp9, VP9, NULL)
 #if CONFIG_AV1_QSV_DECODER
 DEFINE_QSV_DECODER(av1, AV1, NULL)
 #endif
+
+#if CONFIG_VVC_QSV_DECODER
+DEFINE_QSV_DECODER(vvc, VVC, NULL)
+#endif
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 7acb261bb3..37c4c39451 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #include "version_major.h"
 
-#define LIBAVCODEC_VERSION_MINOR   7
+#define LIBAVCODEC_VERSION_MINOR   8
 #define LIBAVCODEC_VERSION_MICRO 100
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
-- 
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".

[FFmpeg-devel] [PATCH 1/2] avfilter/vf_deshake_opencl: Use AV_VIDEO_MAX_PLANES

[Michael Niedermayer]

Fixes: CID1452758 Out-of-bounds read (actual out of bounds access depends on a 
frame with more than 3 planes)

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_deshake_opencl.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_deshake_opencl.c b/libavfilter/vf_deshake_opencl.c
index e49c808a8e2..96e21a069f2 100644
--- a/libavfilter/vf_deshake_opencl.c
+++ b/libavfilter/vf_deshake_opencl.c
@@ -1387,8 +1387,8 @@ static int filter_frame(AVFilterLink *link, AVFrame 
*input_frame)
 size_t global_work[2];
 int64_t duration;
 cl_mem src, transformed, dst;
-cl_mem transforms[3];
-CropInfo crops[3];
+cl_mem transforms[AV_VIDEO_MAX_PLANES];
+CropInfo crops[AV_VIDEO_MAX_PLANES];
 cl_event transform_event, crop_upscale_event;
 DebugMatches debug_matches;
 cl_int num_model_matches;
@@ -1518,7 +1518,7 @@ static int filter_frame(AVFilterLink *link, AVFrame 
*input_frame)
 transforms[0] = deshake_ctx->transform_y;
 transforms[1] = transforms[2] = deshake_ctx->transform_uv;
 
-for (int p = 0; p < FF_ARRAY_ELEMS(transformed_frame->data); p++) {
+for (int p = 0; p < AV_VIDEO_MAX_PLANES; p++) {
 // Transform all of the planes appropriately
 src = (cl_mem)input_frame->data[p];
 transformed = (cl_mem)transformed_frame->data[p];
@@ -1619,7 +1619,7 @@ static int filter_frame(AVFilterLink *link, AVFrame 
*input_frame)
 crops[0] = deshake_ctx->crop_y;
 crops[1] = crops[2] = deshake_ctx->crop_uv;
 
-for (int p = 0; p < FF_ARRAY_ELEMS(cropped_frame->data); p++) {
+for (int p = 0; p < AV_VIDEO_MAX_PLANES; p++) {
 // Crop all of the planes appropriately
 dst = (cl_mem)cropped_frame->data[p];
 transformed = (cl_mem)transformed_frame->data[p];
-- 
2.45.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".

[FFmpeg-devel] [PATCH 2/2] avfilter/vf_deshake_opencl: Ensure that the first iteration initializes the best variables

[Michael Niedermayer]

Fixes: CID1452759 Uninitialized scalar variable

Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer 
---
 libavfilter/vf_deshake_opencl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_deshake_opencl.c b/libavfilter/vf_deshake_opencl.c
index 96e21a069f2..5c3848c3ede 100644
--- a/libavfilter/vf_deshake_opencl.c
+++ b/libavfilter/vf_deshake_opencl.c
@@ -703,7 +703,7 @@ static int minimize_error(
 total_err += deshake_ctx->ransac_err[j];
 }
 
-if (total_err < best_err) {
+if (i == 0 || total_err < best_err) {
 for (int mi = 0; mi < 6; ++mi) {
 best_model[mi] = model[mi];
 }
-- 
2.45.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] aarch64: Use cntvct_el0 as timer register on Android

[Zhao Zhili]

> On Jun 13, 2024, at 20:54, Martin Storsjö  wrote:
> 
> On Fri, 7 Jun 2024, Martin Storsjö wrote:
> 
>> The default timer register pmccntr_el0 usually requires enabling
>> access with e.g. a kernel module.
>> ---
>> cntvct_el0 has significantly better resolution than
>> av_gettime_relative (while the unscaled nanosecond output of
>> clock_gettime is much higher resolution).
>> 
>> In one tested case, the cntvct_el0 timer has a frequency of 25 MHz
>> (readable via the register cntfrq_el0).
>> ---
>> libavutil/aarch64/timer.h | 9 +
>> 1 file changed, 9 insertions(+)
>> 
>> diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
>> index fadc9568f8..966f17081a 100644
>> --- a/libavutil/aarch64/timer.h
>> +++ b/libavutil/aarch64/timer.h
>> @@ -33,7 +33,16 @@ static inline uint64_t read_time(void)
>>uint64_t cycle_counter;
>>__asm__ volatile(
>>"isb   \t\n"
>> +#if defined(__ANDROID__)
>> +// cntvct_el0 has lower resolution than pmccntr_el0, but is usually
>> +// accessible from user space by default.
>> +"mrs %0, cntvct_el0"
>> +#else
>> +// pmccntr_el0 has higher resolution, but is usually not accessible
>> +// from user space by default (but access can be enabled with a 
>> custom
>> +// kernel module).
>>"mrs %0, pmccntr_el0   "
>> +#endif
>>: "=r"(cycle_counter) :: "memory" );
> 
> Zhao, does this implementation seem useful to you? Does it give you better 
> (more accurate, less noisy?) benchmarking numbers on Android, than the 
> fallback based on clock_gettime?

Hi Martin, this works on Android and macOS both, so maybe you can enable it for 
macOS too.

I have compared the result of this implementation and mach_absolute_time, this 
looks like
the implementation has smaller variable Deviation than mach_absolute_time. I 
guess the result
is the same when compared to clock_gettime.

We have linux perf on Android, and kperf on macOS. Linux perf has the benefit 
to reduce interference
from other processes on statistical results, if I understand correctly. I’m not 
sure about the benefit of
macOS kperf.l

> 
> // 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/aaccoder_twoloop: remove unused macro

[Yotam Ofek]

seems the `sclip` macro was never used
---
 libavcodec/aaccoder_twoloop.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
index 92dc2911a3..c1dcdbb5ed 100644
--- a/libavcodec/aaccoder_twoloop.h
+++ b/libavcodec/aaccoder_twoloop.h
@@ -53,8 +53,6 @@
 /** Frequency in Hz for lower limit of noise substitution **/
 #define NOISE_LOW_LIMIT 4000
 
-#define sclip(x) av_clip(x,60,218)
-
 /* Reflects the cost to change codebooks */
 static inline int ff_pns_bits(SingleChannelElement *sce, int w, int g)
 {
-- 
2.40.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] lavc/vvc: Invalidate PPSs which refer to a changed SPS

[Frank Plowman]

When the SPS associated with a particular SPS ID changes, invalidate all
the PPSs which use that SPS ID.  Fixes crashes with illegal bitstreams.
This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
ID reuse validation, as parts of the CBS parsing process for PPSs
depend on the SPS being referred to.

Signed-off-by: Frank Plowman 
---
 libavcodec/cbs_h2645.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index c5f167334d..e2389f124e 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -789,9 +789,28 @@ static int cbs_h26 ## h26n ## _replace_ ## 
ps_var(CodedBitstreamContext *ctx, \
 }
 
 cbs_h266_replace_ps(6, VPS, vps, vps_video_parameter_set_id)
-cbs_h266_replace_ps(6, SPS, sps, sps_seq_parameter_set_id)
 cbs_h266_replace_ps(6, PPS, pps, pps_pic_parameter_set_id)
 
+static int cbs_h266_replace_sps(CodedBitstreamContext *ctx,
+CodedBitstreamUnit *unit)
+{
+CodedBitstreamH266Context *priv = ctx->priv_data;
+H266RawSPS *sps = unit->content;
+unsigned int id = sps->sps_seq_parameter_set_id;
+int err = ff_cbs_make_unit_refcounted(ctx, unit);
+if (err < 0)
+return err;
+av_assert0(unit->content_ref);
+if (priv->sps[id] && memcmp(priv->sps[id], unit->content_ref, 
sizeof(*priv->sps[id]))) {
+for (unsigned int i = 0; i < VVC_MAX_PPS_COUNT; i++) {
+if (priv->pps[i] && priv->pps[i]->pps_seq_parameter_set_id == id)
+ff_refstruct_unref(&priv->pps[i]);
+}
+}
+ff_refstruct_replace(&priv->sps[id], unit->content_ref);
+return 0;
+}
+
 static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit,
H266RawPictureHeader *ph)
-- 
2.45.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/aaccoder_twoloop: remove unread max scaler

[Yotam Ofek]

---
 libavcodec/aaccoder_twoloop.h | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/aaccoder_twoloop.h b/libavcodec/aaccoder_twoloop.h
index c1dcdbb5ed..c56abc68a7 100644
--- a/libavcodec/aaccoder_twoloop.h
+++ b/libavcodec/aaccoder_twoloop.h
@@ -101,7 +101,7 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
  */
 float sfoffs = av_clipf(log2f(120.0f / lambda) * 4.0f, -5, 10);
 
-int fflag, minscaler, maxscaler, nminscaler;
+int fflag, minscaler, nminscaler;
 int its  = 0;
 int maxits = 30;
 int allz = 0;
@@ -572,12 +572,10 @@ static void search_for_quantizers_twoloop(AVCodecContext 
*avctx,
 }
 
 minscaler = SCALE_MAX_POS;
-maxscaler = 0;
 for (w = 0; w < sce->ics.num_windows; w += sce->ics.group_len[w]) {
 for (g = 0;  g < sce->ics.num_swb; g++) {
 if (!sce->zeroes[w*16+g]) {
 minscaler = FFMIN(minscaler, sce->sf_idx[w*16+g]);
-maxscaler = FFMAX(maxscaler, sce->sf_idx[w*16+g]);
 }
 }
 }
-- 
2.40.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] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied with 
the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a number 
of different ways, whereas the hybrid fragmented/non-fragmented only 
is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use both 
types of energy sources. The artifact here will be one _or_ the other.


Sure, the file itself is either or, but the process of writing will have 
utilized both. TBH, I don't see it as such a black-or-white thing.


What do the others who have chimed in on the thread think, compared to 
calling it "recoverable" or "resilient_mode"?


// 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] aarch64: Use cntvct_el0 as timer register on Android

[Martin Storsjö]

On Fri, 14 Jun 2024, Zhao Zhili wrote:





On Jun 13, 2024, at 20:54, Martin Storsjö  wrote:

On Fri, 7 Jun 2024, Martin Storsjö wrote:


The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.
---
cntvct_el0 has significantly better resolution than
av_gettime_relative (while the unscaled nanosecond output of
clock_gettime is much higher resolution).

In one tested case, the cntvct_el0 timer has a frequency of 25 MHz
(readable via the register cntfrq_el0).
---
libavutil/aarch64/timer.h | 9 +
1 file changed, 9 insertions(+)

diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..966f17081a 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -33,7 +33,16 @@ static inline uint64_t read_time(void)
   uint64_t cycle_counter;
   __asm__ volatile(
   "isb   \t\n"
+#if defined(__ANDROID__)
+// cntvct_el0 has lower resolution than pmccntr_el0, but is usually
+// accessible from user space by default.
+"mrs %0, cntvct_el0"
+#else
+// pmccntr_el0 has higher resolution, but is usually not accessible
+// from user space by default (but access can be enabled with a custom
+// kernel module).
   "mrs %0, pmccntr_el0   "
+#endif
   : "=r"(cycle_counter) :: "memory" );


Zhao, does this implementation seem useful to you? Does it give you better 
(more accurate, less noisy?) benchmarking numbers on Android, than the fallback 
based on clock_gettime?


Hi Martin, this works on Android and macOS both, so maybe you can enable it for 
macOS too.

I have compared the result of this implementation and 
mach_absolute_time, this looks like the implementation has smaller 
variable Deviation than mach_absolute_time. I guess the result is the 
same when compared to clock_gettime.


Right, it does seem to use the same scale as mach_absolute_time - but it 
probably has less overhead when we can fetch it by just reading a 
register, instead of calling out to a system function.


So then I guess I could extend this patch to enable it for 
defined(__APPLE__) too.


We have linux perf on Android, and kperf on macOS. Linux perf has the 
benefit to reduce interference from other processes on statistical 
results, if I understand correctly.


Yes, possibly, but on the other hand, it also has a bit more noise and 
overhead over just using pmccntr_el0; if e.g. tuning and comparing small 
differences in functions, pmccntr_el0 usually gives the best result.


But anyway, as those are configurable, users building with linux perf will 
get that, and users disabling it will get the more accurate register 
instead.



I’m not sure about the benefit of macOS kperf.


macOS kperf gives the best and most accurate numbers you can get, on that 
HW, but unfortunately, it's undocumented and unofficial (and requires 
running with sudo). It does give numbers comparable to linux perf, I 
think, i.e. proper clock cycle level numbers.


// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Andreas Rheinhardt]

Andreas Rheinhardt:
> The H.264 decoder does not support draw_horiz_band (it does not have
> the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the default case is display order.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/d3d12va_h264.c | 12 
>  libavcodec/dxva2_h264.c   | 13 -
>  libavcodec/h264_slice.c   |  2 --
>  libavcodec/h264dec.c  | 39 ---
>  libavcodec/h264dec.h  |  2 --
>  libavcodec/vaapi_h264.c   | 11 +--
>  libavcodec/vdpau_h264.c   |  2 --
>  7 files changed, 9 insertions(+), 72 deletions(-)
> 
> diff --git a/libavcodec/d3d12va_h264.c b/libavcodec/d3d12va_h264.c
> index b2fe2955c8..fe23f083df 100644
> --- a/libavcodec/d3d12va_h264.c
> +++ b/libavcodec/d3d12va_h264.c
> @@ -163,14 +163,10 @@ static int d3d12va_h264_end_frame(AVCodecContext *avctx)
>  if (ctx_pic->slice_count <= 0 || ctx_pic->bitstream_size <= 0)
>  return -1;
>  
> -ret = ff_d3d12va_common_end_frame(avctx, h->cur_pic_ptr->f,
> -  &ctx_pic->pp, sizeof(ctx_pic->pp),
> -  &ctx_pic->qm, sizeof(ctx_pic->qm),
> -  update_input_arguments);
> -if (!ret)
> -ff_h264_draw_horiz_band(h, sl, 0, h->avctx->height);
> -
> -return ret;
> +return ff_d3d12va_common_end_frame(avctx, h->cur_pic_ptr->f,
> +   &ctx_pic->pp, sizeof(ctx_pic->pp),
> +   &ctx_pic->qm, sizeof(ctx_pic->qm),
> +   update_input_arguments);
>  }
>  
>  static int d3d12va_h264_decode_init(AVCodecContext *avctx)
> diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
> index 0fe4152625..a6fbf61ea9 100644
> --- a/libavcodec/dxva2_h264.c
> +++ b/libavcodec/dxva2_h264.c
> @@ -502,20 +502,15 @@ static int dxva2_h264_decode_slice(AVCodecContext 
> *avctx,
>  static int dxva2_h264_end_frame(AVCodecContext *avctx)
>  {
>  H264Context *h = avctx->priv_data;
> -H264SliceContext *sl = &h->slice_ctx[0];
>  struct dxva2_picture_context *ctx_pic =
>  h->cur_pic_ptr->hwaccel_picture_private;
> -int ret;
>  
>  if (ctx_pic->slice_count <= 0 || ctx_pic->bitstream_size <= 0)
>  return -1;
> -ret = ff_dxva2_common_end_frame(avctx, h->cur_pic_ptr->f,
> -&ctx_pic->pp, sizeof(ctx_pic->pp),
> -&ctx_pic->qm, sizeof(ctx_pic->qm),
> -commit_bitstream_and_slice_buffer);
> -if (!ret)
> -ff_h264_draw_horiz_band(h, sl, 0, h->avctx->height);
> -return ret;
> +return ff_dxva2_common_end_frame(avctx, h->cur_pic_ptr->f,
> + &ctx_pic->pp, sizeof(ctx_pic->pp),
> + &ctx_pic->qm, sizeof(ctx_pic->qm),
> + commit_bitstream_and_slice_buffer);
>  }
>  
>  #if CONFIG_H264_DXVA2_HWACCEL
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index ce2c4caca1..ceca1d1046 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -2523,8 +2523,6 @@ static void decode_finish_row(const H264Context *h, 
> H264SliceContext *sl)
>  top= 0;
>  }
>  
> -ff_h264_draw_horiz_band(h, sl, top, height);
> -
>  if (h->droppable || h->er.error_occurred)
>  return;
>  
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index fd23e367b4..a09714b714 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -30,7 +30,6 @@
>  #include "config_components.h"
>  
>  #include "libavutil/avassert.h"
> -#include "libavutil/emms.h"
>  #include "libavutil/imgutils.h"
>  #include "libavutil/mem.h"
>  #include "libavutil/opt.h"
> @@ -100,44 +99,6 @@ static void h264_er_decode_mb(void *opaque, int ref, int 
> mv_dir, int mv_type,
>  ff_h264_hl_decode_mb(h, &h->slice_ctx[0]);
>  }
>  
> -void ff_h264_draw_horiz_band(const H264Context *h, H264SliceContext *sl,
> - int y, int height)
> -{
> -AVCodecContext *avctx = h->avctx;
> -const AVFrame   *src  = h->cur_pic.f;
> -const AVPixFmtDescriptor *desc;
> -int offset[AV_NUM_DATA_POINTERS];
> -int vshift;
> -const int field_pic = h->picture_structure != PICT_FRAME;
> -
> -if (!avctx->draw_horiz_band)
> -return;
> -
> -if (field_pic && h->first_field && !(avctx->slice_flags & 
> SLICE_FLAG_ALLOW_FIELD))
> -return;
> -
> -if (field_pic) {
> -height <<= 1;
> -y  <<= 1;
> -}
> -
> -height = FFMIN(height, avctx->height - y);
> -
> -desc   = av_pix_fmt_desc_get(avctx->pix_fmt);
> -vshift = desc->log2_chroma_h;
> -
> -offset[0] = y * src->linesize[0];
> -offset[1] =
> -offset[2] = (y 

Re: [FFmpeg-devel] [PATCH v2] movenc: Add an option for hiding fragments at the end

[Timo Rothenpieler]

On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied 
with the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a number 
of different ways, whereas the hybrid fragmented/non-fragmented only 
is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use 
both types of energy sources. The artifact here will be one _or_ the 
other.


Sure, the file itself is either or, but the process of writing will have 
utilized both. TBH, I don't see it as such a black-or-white thing.


What do the others who have chimed in on the thread think, compared to 
calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance it'll 
become an established term now that OBS presents it quite publicly visible.

___
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] movenc: Add an option for hiding fragments at the end

[Martin Storsjö]

On Fri, 14 Jun 2024, Timo Rothenpieler wrote:


On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied 
with the option name quite yet. I'm pondering if we should call it 
"hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a number 
of different ways, whereas the hybrid fragmented/non-fragmented only 
is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use 
both types of energy sources. The artifact here will be one _or_ the 
other.


Sure, the file itself is either or, but the process of writing will have 
utilized both. TBH, I don't see it as such a black-or-white thing.


What do the others who have chimed in on the thread think, compared to 
calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance it'll 
become an established term now that OBS presents it quite publicly visible.


For context, the same feature in OBS, is documented at e.g. 
https://obsproject.com/kb/hybrid-mp4.


// 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 v2] aarch64: Use cntvct_el0 as timer register on Android and macOS

[Martin Storsjö]

The default timer register pmccntr_el0 usually requires enabling
access with e.g. a kernel module.

On macOS, using cntvct_el0 gives measurements with the same
magnitude as mach_absolute_time (which is used currently), but
possibly with a little less overhead/noise.
---
cntvct_el0 should have less noise than mach_absolute_time or
clock_gettime.

In one tested case, the cntvct_el0 timer has a frequency of 25 MHz
(readable via the register cntfrq_el0).
---
 libavutil/aarch64/timer.h | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavutil/aarch64/timer.h b/libavutil/aarch64/timer.h
index fadc9568f8..922b0c5598 100644
--- a/libavutil/aarch64/timer.h
+++ b/libavutil/aarch64/timer.h
@@ -24,7 +24,7 @@
 #include 
 #include "config.h"
 
-#if HAVE_INLINE_ASM && !defined(__APPLE__)
+#if HAVE_INLINE_ASM
 
 #define AV_READ_TIME read_time
 
@@ -33,7 +33,16 @@ static inline uint64_t read_time(void)
 uint64_t cycle_counter;
 __asm__ volatile(
 "isb   \t\n"
+#if defined(__ANDROID__) || defined(__APPLE__)
+// cntvct_el0 has lower resolution than pmccntr_el0, but is usually
+// accessible from user space by default.
+"mrs %0, cntvct_el0"
+#else
+// pmccntr_el0 has higher resolution, but is usually not accessible
+// from user space by default (but access can be enabled with a custom
+// kernel module).
 "mrs %0, pmccntr_el0   "
+#endif
 : "=r"(cycle_counter) :: "memory" );
 
 return cycle_counter;
-- 
2.39.3 (Apple Git-146)

___
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] movenc: Add an option for hiding fragments at the end

[Gyan Doshi]

On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:

On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied 
with the option name quite yet. I'm pondering if we should call 
it "hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a 
number of different ways, whereas the hybrid 
fragmented/non-fragmented only is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use 
both types of energy sources. The artifact here will be one _or_ the 
other.


Sure, the file itself is either or, but the process of writing will 
have utilized both. TBH, I don't see it as such a black-or-white thing.


What do the others who have chimed in on the thread think, compared 
to calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance 
it'll become an established term now that OBS presents it quite 
publicly visible.


The OBS dev intends to change the term:

"Come up with a better name than "Hybrid MP4" that hopefully won't 
confuse users"

https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024

Regards,
Gyan

___
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 0/1] avfilter/framesync: fix forward EOF pts

[Nicolas Gaullier]

>Envoyé : lundi 3 juin 2024 12:00
>>Envoyé : mardi 28 mai 2024 11:11
>>
>>This a new ping but I post the patch again to get fate cleanly completed on 
>>patchwork.
>>BTW, the initial design of framesync/EOF was in n3.4-dev-1799-g4e0e9ce2dc, so 
>>one can say that time has past...
>>
>>Thank you in advance for the review.
>>Nicolas
>
>Another ping.
>Patch still applies
>https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=11939

Still applies to current master.
Anyone to review ?
To summarize, and for remembering, the initial commit was 4e0e9ce2dc, 7 years 
ago, and inserted this:
ff_outlink_set_status(fs->parent->outputs[0], AVERROR_EOF, AV_NOPTS_VALUE)
The target of this patch is to make it a:
ff_outlink_set_status(fs->parent->outputs[0], AVERROR_EOF, eof_pts)

My use case is that I frequently chain the scale filter with the fps filter,
and since the scale filter use framesync since e82a3997cdd6c0 (3rd of May this 
year),
this is becoming a full issue (yet I have not find any corresponding trac entry 
so far).

Thanks
Nicolas
___
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/8] avdovi/dovi_rpudec: handle prev_vdr_rpu_id failures

[Niklas Haas]

On Sun, 09 Jun 2024 17:05:46 +0200 Niklas Haas  wrote:
> From: Niklas Haas 
> 
> According to the spec, missing previous VDR RPU IDs do not constitute an
> error, but we should instead fallback first to VDR RPU with ID 0, and
> failing that, synthesize "neutral" metadata.
> 
> That's nontrivial though as the resulting metadata will be dependent on
> other properties of the RPU, and this case is not hit in practice so
> I'll defer it to a rainy day.
> ---
>  libavcodec/dovi_rpudec.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
> index 7c7eda9d09..d1dcc3a262 100644
> --- a/libavcodec/dovi_rpudec.c
> +++ b/libavcodec/dovi_rpudec.c
> @@ -444,7 +444,12 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t 
> *rpu, size_t rpu_size,
>  if (use_prev_vdr_rpu) {
>  int prev_vdr_rpu_id = get_ue_golomb_31(gb);
>  VALIDATE(prev_vdr_rpu_id, 0, DOVI_MAX_DM_ID);
> +if (!s->vdr[prev_vdr_rpu_id])
> +prev_vdr_rpu_id = 0;
>  if (!s->vdr[prev_vdr_rpu_id]) {
> +/* FIXME: Technically, the spec says that in this case we should
> + * synthesize "neutral" vdr metadata, but easier to just error
> + * out as this corner case is not hit in practice */
>  av_log(s->logctx, AV_LOG_ERROR, "Unknown previous RPU ID: %u\n",
> prev_vdr_rpu_id);
>  goto fail;
> -- 
> 2.45.1
> 

Ping for review, otherwis will merge soon as it's a lot of relatively
low-hanging fruit that fixes current deviations with the spec.
___
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/2] avcodec/dovi_rpudec: add return code to parse_ext_v*

[Niklas Haas]

From: Niklas Haas 

---
 libavcodec/dovi_rpudec.c | 20 ++--
 1 file changed, 14 insertions(+), 6 deletions(-)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index a477dbd4e3..fc3b0a2b82 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -127,7 +127,7 @@ static inline unsigned get_variable_bits(GetBitContext *gb, 
int n)
 }  
 \
 } while (0)
 
-static void parse_ext_v1(DOVIContext *s, GetBitContext *gb, AVDOVIDmData *dm)
+static int parse_ext_v1(DOVIContext *s, GetBitContext *gb, AVDOVIDmData *dm)
 {
 switch (dm->level) {
 case 1:
@@ -170,6 +170,8 @@ static void parse_ext_v1(DOVIContext *s, GetBitContext *gb, 
AVDOVIDmData *dm)
 av_log(s->logctx, AV_LOG_WARNING,
"Unknown Dolby Vision DM v1 level: %u\n", dm->level);
 }
+
+return 0;
 }
 
 static AVCIExy get_cie_xy(GetBitContext *gb)
@@ -181,8 +183,8 @@ static AVCIExy get_cie_xy(GetBitContext *gb)
 return xy;
 }
 
-static void parse_ext_v2(DOVIContext *s, GetBitContext *gb, AVDOVIDmData *dm,
- int ext_block_length)
+static int parse_ext_v2(DOVIContext *s, GetBitContext *gb, AVDOVIDmData *dm,
+int ext_block_length)
 {
 switch (dm->level) {
 case 3:
@@ -254,11 +256,13 @@ static void parse_ext_v2(DOVIContext *s, GetBitContext 
*gb, AVDOVIDmData *dm,
 av_log(s->logctx, AV_LOG_WARNING,
"Unknown Dolby Vision DM v2 level: %u\n", dm->level);
 }
+
+return 0;
 }
 
 static int parse_ext_blocks(DOVIContext *s, GetBitContext *gb, int ver)
 {
-int num_ext_blocks, ext_block_length, start_pos, parsed_bits;
+int num_ext_blocks, ext_block_length, start_pos, parsed_bits, ret;
 
 num_ext_blocks = get_ue_golomb_31(gb);
 align_get_bits(gb);
@@ -278,10 +282,14 @@ static int parse_ext_blocks(DOVIContext *s, GetBitContext 
*gb, int ver)
 start_pos = get_bits_count(gb);
 
 switch (ver) {
-case 1: parse_ext_v1(s, gb, dm); break;
-case 2: parse_ext_v2(s, gb, dm, ext_block_length); break;
+case 1: ret = parse_ext_v1(s, gb, dm); break;
+case 2: ret = parse_ext_v2(s, gb, dm, ext_block_length); break;
+default: return AVERROR_BUG;
 }
 
+if (ret < 0)
+return ret;
+
 parsed_bits = get_bits_count(gb) - start_pos;
 if (parsed_bits > ext_block_length * 8)
 return AVERROR_INVALIDDATA;
-- 
2.45.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/2] avcodec/dovi_rpudec: validate L2.ms_weight

[Niklas Haas]

From: Niklas Haas 

This is specified to be in the range -1 to 4095, apparently the only
extension level with such a restriction.
---
 libavcodec/dovi_rpudec.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
index fc3b0a2b82..306efbb31f 100644
--- a/libavcodec/dovi_rpudec.c
+++ b/libavcodec/dovi_rpudec.c
@@ -143,6 +143,7 @@ static int parse_ext_v1(DOVIContext *s, GetBitContext *gb, 
AVDOVIDmData *dm)
 dm->l2.trim_chroma_weight = get_bits(gb, 12);
 dm->l2.trim_saturation_gain = get_bits(gb, 12);
 dm->l2.ms_weight = get_sbits(gb, 13);
+VALIDATE(dm->l2.ms_weight, -1, 4095);
 break;
 case 4:
 dm->l4.anchor_pq = get_bits(gb, 12);
@@ -172,6 +173,9 @@ static int parse_ext_v1(DOVIContext *s, GetBitContext *gb, 
AVDOVIDmData *dm)
 }
 
 return 0;
+
+fail:
+return AVERROR_INVALIDDATA;
 }
 
 static AVCIExy get_cie_xy(GetBitContext *gb)
-- 
2.45.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] [BROKEN] apad causes infinite hang

[Paul B Mahol]

Just try with:

ffmpeg -f lavfi -i sine=d=30 -af apad -f null -

Pressing 'q' will not stop it at all, because current ffmpeg code will try
to flush all frames, but because pad filter never receives EOF from next
filter in chain (sink) it will happily produce frame forever.

Tried to fix ffmpeg.c related code but quickly realized rewrite just made
it 10 times worse to debug this.

Most clean solution is adding av_buffersink_close()
___
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/5] lavu/common.h: Fix UB in av_clipl_int32_c()

[Tomas Härdin]

Pushed patches 1-4

/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Kieran Kunhya via ffmpeg-devel]

On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
 wrote:
>
> The H.264 decoder does not support draw_horiz_band (it does not have
> the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> legally dead. The function here always calls draw_horiz_band
> in coded order, although the default case is display order.

Why would you want a low latency decode mode with reordering?
I have no idea about hwaccel, but I believe with low latency encoded
video this does work.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Paul B Mahol]

On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org> wrote:

> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>  wrote:
> >
> > The H.264 decoder does not support draw_horiz_band (it does not have
> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
> > legally dead. The function here always calls draw_horiz_band
> > in coded order, although the default case is display order.
>
> Why would you want a low latency decode mode with reordering?
> I have no idea about hwaccel, but I believe with low latency encoded
> video this does work.
>

Since when?

See 0da71265d84b587c7159cd82708ca60ad050dd4c from 2003.

flag remain commented out from then to this day.


> Kieran
> ___
> 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 1/5] avutil/spherical: Add more spherical types

[Derek Buitenhuis]

On 6/11/2024 7:44 PM, James Almer wrote:
> This should ideally be the enum with value 0, but until next major when 
> such a change can happen, it would be IMO a good idea if you set 
> spherical->projection to AV_SPHERICAL_RECTANGULAR in av_spherical_alloc().

I think setting it to 0 (AV_STEREO3D_2D) is correct rather than this (and is 
already
done), and I don't think we need to reorder.

I had discussed this with Vittorio and it was decided that it was good to 
disambiguate
between 2D (not stereoscopic) and coded rectangular.

- Derek

___
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 3/5] fftools/ffprobe: Print more Stereo 3D info from side data

[Derek Buitenhuis]

On 6/11/2024 7:43 PM, Derek Buitenhuis wrote:
> Perhaps if type!=2D?

Changed locally to this and updated the test.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264dec: Remove ff_h264_draw_horiz_band

[Kieran Kunhya via ffmpeg-devel]

On Fri, Jun 14, 2024 at 1:53 PM Paul B Mahol  wrote:
>
>
>
> On Fri, Jun 14, 2024 at 2:41 PM Kieran Kunhya via ffmpeg-devel 
>  wrote:
>>
>> On Sun, Jun 9, 2024 at 2:39 AM Andreas Rheinhardt
>>  wrote:
>> >
>> > The H.264 decoder does not support draw_horiz_band (it does not have
>> > the AV_CODEC_CAP_DRAW_HORIZ_BAND), making ff_h264_draw_horiz_band()
>> > legally dead. The function here always calls draw_horiz_band
>> > in coded order, although the default case is display order.
>>
>> Why would you want a low latency decode mode with reordering?
>> I have no idea about hwaccel, but I believe with low latency encoded
>> video this does work.
>
>
> Since when?
>
> See 0da71265d84b587c7159cd82708ca60ad050dd4c from 2003.
>
> flag remain commented out from then to this day.

It still worked if you controlled the input.

Kieran
___
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/4] lavc/mpegvideo: use H263DSP dequant function

[James Almer]

On 6/12/2024 1:47 AM, Rémi Denis-Courmont wrote:

---
  configure  |  4 ++--
  libavcodec/mpegvideo.c | 46 +++---
  2 files changed, 14 insertions(+), 36 deletions(-)

diff --git a/configure b/configure
index 6baa9b0646..eb9d1b1f5d 100755
--- a/configure
+++ b/configure
@@ -2957,8 +2957,8 @@ ftr_decoder_select="adts_header"
  g2m_decoder_deps="zlib"
  g2m_decoder_select="blockdsp idctdsp jpegtables"
  g729_decoder_select="audiodsp"
-h261_decoder_select="mpegvideodec"
-h261_encoder_select="mpegvideoenc"
+h261_decoder_select="h263dsp mpegvideodec"
+h261_encoder_select="h263dsp mpegvideoenc"
  h263_decoder_select="h263_parser h263dsp mpegvideodec qpeldsp"
  h263_encoder_select="h263dsp mpegvideoenc"
  h263i_decoder_select="h263_decoder"
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 7af823b8bd..b35fd37083 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -201,13 +201,11 @@ static void dct_unquantize_mpeg2_inter_c(MpegEncContext 
*s,
  static void dct_unquantize_h263_intra_c(MpegEncContext *s,
int16_t *block, int n, int qscale)
  {
-int i, level, qmul, qadd;
-int nCoeffs;
+int qmul = qscale << 1;
+int qadd, nCoeffs;
  
  av_assert2(s->block_last_index[n]>=0 || s->h263_aic);
  
-qmul = qscale << 1;

-
  if (!s->h263_aic) {
  block[0] *= n < 4 ? s->y_dc_scale : s->c_dc_scale;
  qadd = (qscale - 1) | 1;
@@ -215,47 +213,24 @@ static void dct_unquantize_h263_intra_c(MpegEncContext *s,
  qadd = 0;
  }
  if(s->ac_pred)
-nCoeffs=63;
+nCoeffs = 64;
  else
-nCoeffs= s->intra_scantable.raster_end[ s->block_last_index[n] ];
+nCoeffs = s->intra_scantable.raster_end[s->block_last_index[n]] + 1;
  
-for(i=1; i<=nCoeffs; i++) {

-level = block[i];
-if (level) {
-if (level < 0) {
-level = level * qmul - qadd;
-} else {
-level = level * qmul + qadd;
-}
-block[i] = level;
-}
-}
+s->h263dsp.h263_dct_unquantize_intra(block, nCoeffs, qmul, qadd);


Looking further into this, you're adding a function pointer call in a 
function that's already called from a function pointer. And both x86 and 
arm have asm optimized versions of this entire method, which includes 
all the setup before the loop.


Can't you do the same for riscv? Is there anything preventing you from 
accessing fields at specific offsets within MpegEncContext?



  }
  
  static void dct_unquantize_h263_inter_c(MpegEncContext *s,

int16_t *block, int n, int qscale)
  {
-int i, level, qmul, qadd;
+int qmul = qscale << 1;
+int qadd = (qscale - 1) | 1;
  int nCoeffs;
  
  av_assert2(s->block_last_index[n]>=0);
  
-qadd = (qscale - 1) | 1;

-qmul = qscale << 1;
-
-nCoeffs= s->inter_scantable.raster_end[ s->block_last_index[n] ];
-
-for(i=0; i<=nCoeffs; i++) {
-level = block[i];
-if (level) {
-if (level < 0) {
-level = level * qmul - qadd;
-} else {
-level = level * qmul + qadd;
-}
-block[i] = level;
-}
-}
+nCoeffs = s->inter_scantable.raster_end[s->block_last_index[n]] + 1;
+s->h263dsp.h263_dct_unquantize_inter(block, nCoeffs, qmul, qadd);
  }
  
  
@@ -275,6 +250,9 @@ static void gray8(uint8_t *dst, const uint8_t *src, ptrdiff_t linesize, int h)

  static av_cold int dct_init(MpegEncContext *s)
  {
  ff_blockdsp_init(&s->bdsp);
+#if CONFIG_H263DSP
+ff_h263dsp_init(&s->h263dsp);
+#endif
  ff_hpeldsp_init(&s->hdsp, s->avctx->flags);
  ff_videodsp_init(&s->vdsp, s->avctx->bits_per_raw_sample);
  

___
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/4] lavc/mpegvideo: use H263DSP dequant function

[Rémi Denis-Courmont]

Le 14 juin 2024 17:33:16 GMT+03:00, James Almer  a écrit :
>On 6/12/2024 1:47 AM, Rémi Denis-Courmont wrote:
>> ---
>>   configure  |  4 ++--
>>   libavcodec/mpegvideo.c | 46 +++---
>>   2 files changed, 14 insertions(+), 36 deletions(-)
>> 
>> diff --git a/configure b/configure
>> index 6baa9b0646..eb9d1b1f5d 100755
>> --- a/configure
>> +++ b/configure
>> @@ -2957,8 +2957,8 @@ ftr_decoder_select="adts_header"
>>   g2m_decoder_deps="zlib"
>>   g2m_decoder_select="blockdsp idctdsp jpegtables"
>>   g729_decoder_select="audiodsp"
>> -h261_decoder_select="mpegvideodec"
>> -h261_encoder_select="mpegvideoenc"
>> +h261_decoder_select="h263dsp mpegvideodec"
>> +h261_encoder_select="h263dsp mpegvideoenc"
>>   h263_decoder_select="h263_parser h263dsp mpegvideodec qpeldsp"
>>   h263_encoder_select="h263dsp mpegvideoenc"
>>   h263i_decoder_select="h263_decoder"
>> diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
>> index 7af823b8bd..b35fd37083 100644
>> --- a/libavcodec/mpegvideo.c
>> +++ b/libavcodec/mpegvideo.c
>> @@ -201,13 +201,11 @@ static void 
>> dct_unquantize_mpeg2_inter_c(MpegEncContext *s,
>>   static void dct_unquantize_h263_intra_c(MpegEncContext *s,
>> int16_t *block, int n, int qscale)
>>   {
>> -int i, level, qmul, qadd;
>> -int nCoeffs;
>> +int qmul = qscale << 1;
>> +int qadd, nCoeffs;
>> av_assert2(s->block_last_index[n]>=0 || s->h263_aic);
>>   -qmul = qscale << 1;
>> -
>>   if (!s->h263_aic) {
>>   block[0] *= n < 4 ? s->y_dc_scale : s->c_dc_scale;
>>   qadd = (qscale - 1) | 1;
>> @@ -215,47 +213,24 @@ static void dct_unquantize_h263_intra_c(MpegEncContext 
>> *s,
>>   qadd = 0;
>>   }
>>   if(s->ac_pred)
>> -nCoeffs=63;
>> +nCoeffs = 64;
>>   else
>> -nCoeffs= s->intra_scantable.raster_end[ s->block_last_index[n] ];
>> +nCoeffs = s->intra_scantable.raster_end[s->block_last_index[n]] + 1;
>>   -for(i=1; i<=nCoeffs; i++) {
>> -level = block[i];
>> -if (level) {
>> -if (level < 0) {
>> -level = level * qmul - qadd;
>> -} else {
>> -level = level * qmul + qadd;
>> -}
>> -block[i] = level;
>> -}
>> -}
>> +s->h263dsp.h263_dct_unquantize_intra(block, nCoeffs, qmul, qadd);
>
>Looking further into this, you're adding a function pointer call in a function 
>that's already called from a function pointer. And both x86 and arm have asm 
>optimized versions of this entire method, which includes all the setup before 
>the loop.

I am not interested in copying existing bad design. Note that the Arm code uses 
intrinsics. I don't want to use RVV intrinsics especially just for this. And 
x86 only has MMX.

>Can't you do the same for riscv?

Sure, RV can address fixed offsets up to +/-2 KiB. If someone *else* adds a 
assembler-friendly header file that defines the offsets to the relevant context 
fields, and rewrites the checkasm code to match, that is.

> Is there anything preventing you from accessing fields at specific offsets 
> within MpegEncContext?

My strong belief that that would be technically wrong, yes.
___
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/4] lavc/mpegvideo: use H263DSP dequant function

[Rémi Denis-Courmont]

Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a écrit :
> And x86 only has MMX.

And the x86 code uses inline assembler. That's not viable on any ISA with sane 
conventions such as Arm or RISC-V. The compiler will reject our vector 
clobbers, unless the Vector extension is included in the compilation target. 
But then that breaks run-time detection, and will be rejected by all Linux 
distros.

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
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/4] lavc/mpegvideo: use H263DSP dequant function

[James Almer]

On 6/14/2024 12:11 PM, Rémi Denis-Courmont wrote:

Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a écrit :

And x86 only has MMX.


And the x86 code uses inline assembler. That's not viable on any ISA with sane
conventions such as Arm or RISC-V. The compiler will reject our vector
clobbers, unless the Vector extension is included in the compilation target.
But then that breaks run-time detection, and will be rejected by all Linux
distros.


I was thinking on removing that inline version and probably replacing it 
with sse2, using the dsp prototypes you introduce in this set.

___
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/4] checkasm: add tests for {lum, chr}ConvertRange

[Ramiro Polla]

On Tue, Jun 11, 2024 at 2:29 PM Ramiro Polla  wrote:
>
> ---
>  tests/checkasm/Makefile   |   2 +-
>  tests/checkasm/checkasm.c |   1 +
>  tests/checkasm/checkasm.h |   1 +
>  tests/checkasm/sw_range_convert.c | 134 ++
>  4 files changed, 137 insertions(+), 1 deletion(-)
>  create mode 100644 tests/checkasm/sw_range_convert.c
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 6eb94d10d5..f20732b37a 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -63,7 +63,7 @@ AVFILTEROBJS-$(CONFIG_SOBEL_FILTER)  += vf_convolution.o
>  CHECKASMOBJS-$(CONFIG_AVFILTER) += $(AVFILTEROBJS-yes)
>
>  # swscale tests
> -SWSCALEOBJS += sw_gbrp.o sw_rgb.o sw_scale.o
> +SWSCALEOBJS += sw_gbrp.o sw_range_convert.o 
> sw_rgb.o sw_scale.o
>
>  CHECKASMOBJS-$(CONFIG_SWSCALE)  += $(SWSCALEOBJS)
>
> diff --git a/tests/checkasm/checkasm.c b/tests/checkasm/checkasm.c
> index 2329e2e1bc..56232ab1e0 100644
> --- a/tests/checkasm/checkasm.c
> +++ b/tests/checkasm/checkasm.c
> @@ -251,6 +251,7 @@ static const struct {
>  #endif
>  #if CONFIG_SWSCALE
>  { "sw_gbrp", checkasm_check_sw_gbrp },
> +{ "sw_range_convert", checkasm_check_sw_range_convert },
>  { "sw_rgb", checkasm_check_sw_rgb },
>  { "sw_scale", checkasm_check_sw_scale },
>  #endif
> diff --git a/tests/checkasm/checkasm.h b/tests/checkasm/checkasm.h
> index 211d7f52e6..e544007b67 100644
> --- a/tests/checkasm/checkasm.h
> +++ b/tests/checkasm/checkasm.h
> @@ -119,6 +119,7 @@ void checkasm_check_rv40dsp(void);
>  void checkasm_check_svq1enc(void);
>  void checkasm_check_synth_filter(void);
>  void checkasm_check_sw_gbrp(void);
> +void checkasm_check_sw_range_convert(void);
>  void checkasm_check_sw_rgb(void);
>  void checkasm_check_sw_scale(void);
>  void checkasm_check_takdsp(void);
> diff --git a/tests/checkasm/sw_range_convert.c 
> b/tests/checkasm/sw_range_convert.c
> new file mode 100644
> index 00..08029103d1
> --- /dev/null
> +++ b/tests/checkasm/sw_range_convert.c
> @@ -0,0 +1,134 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 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 General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include 
> +
> +#include "libavutil/common.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/mem_internal.h"
> +
> +#include "libswscale/swscale.h"
> +#include "libswscale/swscale_internal.h"
> +
> +#include "checkasm.h"
> +
> +static void check_lumConvertRange(int from)
> +{
> +const char *func_str = from ? "lumRangeFromJpeg" : "lumRangeToJpeg";
> +#define LARGEST_INPUT_SIZE 512
> +#define INPUT_SIZES 6
> +static const int input_sizes[] = {8, 24, 128, 144, 256, 512};
> +struct SwsContext *ctx;
> +
> +LOCAL_ALIGNED_32(int16_t, dst0, [LARGEST_INPUT_SIZE]);
> +LOCAL_ALIGNED_32(int16_t, dst1, [LARGEST_INPUT_SIZE]);
> +
> +declare_func(void, int16_t *dst, int width);
> +
> +ctx = sws_alloc_context();
> +if (sws_init_context(ctx, NULL, NULL) < 0)
> +fail();
> +
> +ctx->srcFormat = from ? AV_PIX_FMT_YUVJ444P : AV_PIX_FMT_YUV444P;
> +ctx->dstFormat = from ? AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
> +ctx->srcRange = from;
> +ctx->dstRange = !from;
> +
> +for (int dstWi = 0; dstWi < INPUT_SIZES; dstWi++) {
> +int width = input_sizes[dstWi];
> +for (int i = 0; i < width; i++) {
> +uint8_t r = rnd();
> +dst0[i] = (int16_t) r << 7;
> +dst1[i] = (int16_t) r << 7;
> +}
> +ff_sws_init_scale(ctx);
> +if (check_func(ctx->lumConvertRange, "%s_%d", func_str, width)) {
> +call_ref(dst0, width);
> +call_new(dst1, width);
> +if (memcmp(dst0, dst1, width * sizeof(int16_t)))
> +fail();
> +bench_new(dst1, width);
> +}
> +}
> +
> +sws_freeContext(ctx);
> +}
> +#undef LARGEST_INPUT_SIZE
> +#undef INPUT_SIZES
> +
> +static void check_chrConvertRange(int from)
> +{
> +const char *func_str = from ? "chrRangeFromJpeg" : "chrRangeToJpeg";
> +#define LARGEST_INPUT_SIZE 512
> +#define INPUT_SIZES 6
> +static const int input_sizes[] = {8, 24, 128, 144, 256, 512};
> +struct SwsContext *ctx;
> +

Re: [FFmpeg-devel] [PATCH v2 2/4] swscale/x86: add sse4 {lum, chr}ConvertRange

[Ramiro Polla]

On Wed, Jun 12, 2024 at 4:54 PM Ramiro Polla  wrote:
>
> Hi,
>
> On Tue, Jun 11, 2024 at 8:42 PM James Almer  wrote:
> >
> > On 6/11/2024 3:26 PM, Michael Niedermayer wrote:
> > > On Tue, Jun 11, 2024 at 02:28:56PM +0200, Ramiro Polla wrote:
> > >> chrRangeFromJpeg_8_c: 28.7
> > >> chrRangeFromJpeg_8_sse4: 16.2
> > >> chrRangeFromJpeg_24_c: 152.7
> > >> chrRangeFromJpeg_24_sse4: 29.7
> > >> chrRangeFromJpeg_128_c: 366.5
> > >> chrRangeFromJpeg_128_sse4: 233.0
> > >> chrRangeFromJpeg_144_c: 408.0
> > >> chrRangeFromJpeg_144_sse4: 182.5
> > >> chrRangeFromJpeg_256_c: 698.7
> > >> chrRangeFromJpeg_256_sse4: 325.5
> > >> chrRangeFromJpeg_512_c: 1348.7
> > >> chrRangeFromJpeg_512_sse4: 660.2
> > >> chrRangeToJpeg_8_c: 37.7
> > >> chrRangeToJpeg_8_sse4: 16.2
> > >> chrRangeToJpeg_24_c: 115.7
> > >> chrRangeToJpeg_24_sse4: 36.2
> > >> chrRangeToJpeg_128_c: 631.2
> > >> chrRangeToJpeg_128_sse4: 163.7
> > >> chrRangeToJpeg_144_c: 710.7
> > >> chrRangeToJpeg_144_sse4: 183.0
> > >> chrRangeToJpeg_256_c: 1253.0
> > >> chrRangeToJpeg_256_sse4: 343.5
> > >> chrRangeToJpeg_512_c: 2491.2
> > >> chrRangeToJpeg_512_sse4: 654.2
> > >> lumRangeFromJpeg_8_c: 11.7
> > >> lumRangeFromJpeg_8_sse4: 10.5
> > >> lumRangeFromJpeg_24_c: 38.5
> > >> lumRangeFromJpeg_24_sse4: 19.0
> > >> lumRangeFromJpeg_128_c: 237.5
> > >> lumRangeFromJpeg_128_sse4: 79.2
> > >> lumRangeFromJpeg_144_c: 255.7
> > >> lumRangeFromJpeg_144_sse4: 90.5
> > >> lumRangeFromJpeg_256_c: 441.5
> > >> lumRangeFromJpeg_256_sse4: 161.7
> > >> lumRangeFromJpeg_512_c: 879.0
> > >> lumRangeFromJpeg_512_sse4: 333.2
> > >> lumRangeToJpeg_8_c: 20.0
> > >> lumRangeToJpeg_8_sse4: 11.7
> > >> lumRangeToJpeg_24_c: 61.5
> > >> lumRangeToJpeg_24_sse4: 17.7
> > >> lumRangeToJpeg_128_c: 357.5
> > >> lumRangeToJpeg_128_sse4: 80.0
> > >> lumRangeToJpeg_144_c: 371.5
> > >> lumRangeToJpeg_144_sse4: 93.2
> > >> lumRangeToJpeg_256_c: 651.5
> > >> lumRangeToJpeg_256_sse4: 164.5
> > >> lumRangeToJpeg_512_c: 1279.0
> > >> lumRangeToJpeg_512_sse4: 333.7
> > >> ---
> > >>   libswscale/swscale_internal.h|   1 +
> > >>   libswscale/utils.c   |   2 +
> > >>   libswscale/x86/Makefile  |   1 +
> > >>   libswscale/x86/range_convert.asm | 130 +++
> > >>   libswscale/x86/swscale.c |  36 +
> > >>   5 files changed, 170 insertions(+)
> > >>   create mode 100644 libswscale/x86/range_convert.asm
> > >
> > > breaks x86-32 build
> > >
> > > LDffmpeg_g
> > > /usr/lib/gcc-cross/i686-linux-gnu/7/../../../../i686-linux-gnu/bin/ld: 
> > > libswscale/libswscale.a(utils.o): in function `sws_setColorspaceDetails':
> > > ffmpeg/linux32/src/libswscale/utils.c:1086: undefined reference to 
> > > `ff_sws_init_range_convert_x86'
> > > collect2: error: ld returned 1 exit status
> > > make: *** [Makefile:139: ffmpeg_g] Error 1
> > >
> > > thx
> >
> > The functions are wrapped in ARCH_X86_64 checks for seemingly no reason,
> > so they should be removed in the next iteration.
>
> Fixed.
>
> James walked me through on IRC to optimize and improve the functions
> in a way that they work both with sse2 and avx2. New patch attached.

I'll apply tomorrow if there are no more comments.
___
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 58/67] avcodec/h261enc, msmpeg4: Avoid setting dc_scale_tables unnecessarily

[Andreas Rheinhardt]

It is unnecessary because ff_mpeg1_dc_scale_table is the default
for both dc_scale_tables.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261enc.c | 3 ---
 libavcodec/msmpeg4.c | 4 +---
 2 files changed, 1 insertion(+), 6 deletions(-)

diff --git a/libavcodec/h261enc.c b/libavcodec/h261enc.c
index 01bce533a0..dd4419ec8c 100644
--- a/libavcodec/h261enc.c
+++ b/libavcodec/h261enc.c
@@ -34,7 +34,6 @@
 #include "mpegvideo.h"
 #include "h261.h"
 #include "h261enc.h"
-#include "mpegvideodata.h"
 #include "mpegvideoenc.h"
 
 static uint8_t uni_h261_rl_len [64*64*2*2];
@@ -388,8 +387,6 @@ av_cold int ff_h261_encode_init(MpegEncContext *s)
 
 s->min_qcoeff   = -127;
 s->max_qcoeff   = 127;
-s->y_dc_scale_table =
-s->c_dc_scale_table = ff_mpeg1_dc_scale_table;
 s->ac_esc_length= 6+6+8;
 
 s->intra_ac_vlc_length  = s->inter_ac_vlc_length  = 
uni_h261_rl_len;
diff --git a/libavcodec/msmpeg4.c b/libavcodec/msmpeg4.c
index 50fd581a83..872dc8db67 100644
--- a/libavcodec/msmpeg4.c
+++ b/libavcodec/msmpeg4.c
@@ -41,7 +41,6 @@
 #include "mpeg4videodata.h"
 #include "msmpeg4data.h"
 #include "msmpeg4_vc1_data.h"
-#include "mpegvideodata.h"
 
 /*
  * You can also call this codec: MPEG-4 with a twist!
@@ -122,8 +121,7 @@ av_cold void ff_msmpeg4_common_init(MpegEncContext *s)
 switch(s->msmpeg4_version){
 case MSMP4_V1:
 case MSMP4_V2:
-s->y_dc_scale_table=
-s->c_dc_scale_table= ff_mpeg1_dc_scale_table;
+// Correct *_dc_scale_tables (ff_mpeg1_dc_scale_table) is the default
 break;
 case MSMP4_V3:
 if(s->workaround_bugs){
-- 
2.40.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 59/67] avcodec/h261dec: Unquantize coefficients while parsing them

[Andreas Rheinhardt]

This is beneficial for performance: When concatenating
the file from the vsynth1-h261 fate-test 100 times,
performance (measured by timing the codec's decode callback)
improved by 9.6%.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261dec.c | 11 +--
 libavcodec/mpegvideo_dec.c   | 11 ++-
 libavcodec/mpegvideo_enc.c   |  2 +-
 libavcodec/mpv_reconstruct_mb_template.c | 24 
 4 files changed, 28 insertions(+), 20 deletions(-)

diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index f1c1e1a48a..6df8588bb6 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -244,6 +244,7 @@ static int h261_decode_block(H261DecContext *h, int16_t 
*block, int n, int coded
 int level, i, j, run;
 const RLTable *rl = &ff_h261_rl_tcoeff;
 const uint8_t *scan_table;
+const int qmul = s->qscale << 1, qadd = (s->qscale - 1) | 1;
 
 /* For the variable length encoding there are two code tables, one being
  * used for the first transmitted LEVEL in INTER, INTER + MC and
@@ -265,7 +266,7 @@ static int h261_decode_block(H261DecContext *h, int16_t 
*block, int n, int coded
  * being coded as  . */
 if (level == 255)
 level = 128;
-block[0] = level;
+block[0] = level * s->y_dc_scale;
 i= 1;
 } else if (coded) {
 // Run  Level   Code
@@ -276,7 +277,8 @@ static int h261_decode_block(H261DecContext *h, int16_t 
*block, int n, int coded
 i = 0;
 if (check & 0x2) {
 skip_bits(&s->gb, 2);
-block[0] = (check & 0x1) ? -1 : 1;
+block[0] = qmul + qadd;
+block[0] *= (check & 0x1) ? -1 : 1;
 i= 1;
 }
 } else {
@@ -306,10 +308,15 @@ static int h261_decode_block(H261DecContext *h, int16_t 
*block, int n, int coded
 run   = SHOW_UBITS(re, &s->gb, 6) + 1;
 SKIP_CACHE(re, &s->gb, 6);
 level = SHOW_SBITS(re, &s->gb, 8);
+if (level > 0)
+level = level * qmul + qadd;
+else if (level < 0)
+level = level * qmul - qadd;
 SKIP_COUNTER(re, &s->gb, 6 + 8);
 } else if (level == 0) {
 break;
 } else {
+level = level * qmul + qadd;
 if (SHOW_UBITS(re, &s->gb, 1))
 level = -level;
 SKIP_COUNTER(re, &s->gb, 1);
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 684f31947c..da88a35120 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -927,15 +927,16 @@ void ff_mpv_reconstruct_mb(MpegEncContext *s, int16_t 
block[12][64])
}
 }
 
+av_assert2((s->out_format <= FMT_H261) == (s->out_format == FMT_H261 || 
s->out_format == FMT_MPEG1));
 if (!s->avctx->lowres) {
 #if !CONFIG_SMALL
-if (s->out_format == FMT_MPEG1)
-mpv_reconstruct_mb_internal(s, block, 0, DEFINITELY_MPEG12);
+if (s->out_format <= FMT_H261)
+mpv_reconstruct_mb_internal(s, block, 0, DEFINITELY_MPEG12_H261);
 else
-mpv_reconstruct_mb_internal(s, block, 0, NOT_MPEG12);
+mpv_reconstruct_mb_internal(s, block, 0, NOT_MPEG12_H261);
 #else
-mpv_reconstruct_mb_internal(s, block, 0, MAY_BE_MPEG12);
+mpv_reconstruct_mb_internal(s, block, 0, MAY_BE_MPEG12_H261);
 #endif
 } else
-mpv_reconstruct_mb_internal(s, block, 1, MAY_BE_MPEG12);
+mpv_reconstruct_mb_internal(s, block, 1, MAY_BE_MPEG12_H261);
 }
diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 125d16e694..d05a93d249 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -1101,7 +1101,7 @@ static void mpv_reconstruct_mb(MpegEncContext *s, int16_t 
block[12][64])
}
 }
 
-mpv_reconstruct_mb_internal(s, block, 0, MAY_BE_MPEG12);
+mpv_reconstruct_mb_internal(s, block, 0, MAY_BE_MPEG12_H261);
 }
 
 static int get_sae(const uint8_t *src, int ref, int stride)
diff --git a/libavcodec/mpv_reconstruct_mb_template.c 
b/libavcodec/mpv_reconstruct_mb_template.c
index 4b16974827..dca982ae0f 100644
--- a/libavcodec/mpv_reconstruct_mb_template.c
+++ b/libavcodec/mpv_reconstruct_mb_template.c
@@ -20,9 +20,9 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#define NOT_MPEG120
-#define MAY_BE_MPEG12 1
-#define DEFINITELY_MPEG12 2
+#define NOT_MPEG12_H2610
+#define MAY_BE_MPEG12_H261 1
+#define DEFINITELY_MPEG12_H261 2
 
 /* put block[] to dest[] */
 static inline void put_dct(MpegEncContext *s,
@@ -56,14 +56,14 @@ static av_always_inline
 void mpv_reconstruct_mb_internal(MpegEncContext *s, int16_t block[12][64],
  int lowres_flag, int is_mpeg12)
 {
-#define IS_MPEG12(s) (is_mpeg12 == MAY_BE_MPEG12 ? ((s)->out_format == 
FMT_MPEG1) : is_mpeg12)
+#define IS_MPEG12_H261(s)

[FFmpeg-devel] [PATCH 60/67] avcodec/h261dec: Simplify decoding motion vectors

[Andreas Rheinhardt]

Don't use a LUT to negate followed by a conditional ordinary
negation immediately thereafter. Instead fold the two.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261dec.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 6df8588bb6..852de8d535 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -208,10 +208,6 @@ static int h261_decode_mb_skipped(H261DecContext *h, int 
mba1, int mba2)
 return 0;
 }
 
-static const int mvmap[17] = {
-0, -1, -2, -3, -4, -5, -6, -7, -8, -9, -10, -11, -12, -13, -14, -15, -16
-};
-
 static int decode_mv_component(GetBitContext *gb, int v)
 {
 int mv_diff = get_vlc2(gb, h261_mv_vlc, H261_MV_VLC_BITS, 2);
@@ -220,9 +216,7 @@ static int decode_mv_component(GetBitContext *gb, int v)
 if (mv_diff < 0)
 return v;
 
-mv_diff = mvmap[mv_diff];
-
-if (mv_diff && !get_bits1(gb))
+if (mv_diff && get_bits1(gb))
 mv_diff = -mv_diff;
 
 v += mv_diff;
-- 
2.40.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 61/67] avcodec/h261dec: Don't set framerate multiple times

[Andreas Rheinhardt]

Just do it one during init.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h261dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h261dec.c b/libavcodec/h261dec.c
index 852de8d535..cabca33c8d 100644
--- a/libavcodec/h261dec.c
+++ b/libavcodec/h261dec.c
@@ -87,6 +87,8 @@ static av_cold int h261_decode_init(AVCodecContext *avctx)
 MpegEncContext *const s = &h->s;
 int ret;
 
+avctx->framerate = (AVRational) { 3, 1001 };
+
 s->private_ctx = &h->common;
 // set defaults
 ret = ff_mpv_decode_init(s, avctx);
@@ -473,8 +475,6 @@ static int h261_decode_picture_header(H261DecContext *h)
 /* temporal reference */
 skip_bits(&s->gb, 5); /* picture timestamp */
 
-s->avctx->framerate = (AVRational) { 3, 1001 };
-
 /* PTYPE starts here */
 skip_bits1(&s->gb); /* split screen off */
 skip_bits1(&s->gb); /* camera  off */
-- 
2.40.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 62/67] avcodec/rv10: Remove write-only assignments

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/rv10.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 3dcee0a065..c6baaa0269 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -498,12 +498,6 @@ static int rv10_decode_packet(AVCodecContext *avctx, const 
uint8_t *buf,
 s->rv10_first_dc_coded[0] = 0;
 s->rv10_first_dc_coded[1] = 0;
 s->rv10_first_dc_coded[2] = 0;
-s->block_wrap[0] =
-s->block_wrap[1] =
-s->block_wrap[2] =
-s->block_wrap[3] = s->b8_stride;
-s->block_wrap[4] =
-s->block_wrap[5] = s->mb_stride;
 ff_init_block_index(s);
 
 /* decode each macroblock */
-- 
2.40.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 63/67] avcodec/mpeg_er: Simplify disabling IDCT

[Andreas Rheinhardt]

The error resilience code does not make up block coefficients
and therefore zeroes them in order to disable the IDCT.
But this can be done in a simpler manner, namely by setting
block_last_index to a negative value. Doing so also has
the advantage that the dct_unquantize functions are never even
called for those codecs that do not use ff_mpv_reconstruct_mb()
for ordinary decoding (namely RV-30/40 and the VC-1 family).

This approach would not work for intra macroblocks (there is always
at least one coefficient for them and therefore there is no check
for block_last_index for them), but this does not happen at all.
Add an assert for this.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg_er.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg_er.c b/libavcodec/mpeg_er.c
index fe7dcd7efb..3cbdeeebec 100644
--- a/libavcodec/mpeg_er.c
+++ b/libavcodec/mpeg_er.c
@@ -16,6 +16,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "libavutil/avassert.h"
 #include "libavutil/mem.h"
 #include "error_resilience.h"
 #include "mpegvideo.h"
@@ -67,6 +68,8 @@ static void mpeg_er_decode_mb(void *opaque, int ref, int 
mv_dir, int mv_type,
 {
 MpegEncContext *s = opaque;
 
+av_assert1(!mb_intra);
+
 s->mv_dir = mv_dir;
 s->mv_type= mv_type;
 s->mb_intra   = mb_intra;
@@ -76,9 +79,9 @@ static void mpeg_er_decode_mb(void *opaque, int ref, int 
mv_dir, int mv_type,
 s->mcsel  = 0;
 memcpy(s->mv, mv, sizeof(*mv));
 
-s->bdsp.clear_blocks(s->block[0]);
-if (!s->chroma_y_shift)
-s->bdsp.clear_blocks(s->block[6]);
+// The following disables the IDCT.
+for (size_t i = 0; i < FF_ARRAY_ELEMS(s->block_last_index); i++)
+s->block_last_index[i] = -1;
 
 s->dest[0] = s->cur_pic.data[0] +
  s->mb_y * 16 * s->linesize +
-- 
2.40.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 64/67] avcodec/rv10: Use ff_h263_decode_init()

[Andreas Rheinhardt]

The RV10 and RV20 decoders use ff_h263_decode_mb() and also the
H.263 DSP and VLCs. Despite not calling ff_h263_decode_frame(),
it is nevertheless beneficial to call ff_h263_decode_init()
to reduce code duplication.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c |  2 ++
 libavcodec/rv10.c| 19 +++
 2 files changed, 5 insertions(+), 16 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 75fcf1..19a57582ad 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -135,6 +135,8 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 s->msmpeg4_version = MSMP4_WMV2;
 break;
 case AV_CODEC_ID_H263I:
+case AV_CODEC_ID_RV10:
+case AV_CODEC_ID_RV20:
 break;
 case AV_CODEC_ID_FLV1:
 s->h263_flv = 1;
diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index c6baaa0269..65060d4ece 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -346,7 +346,6 @@ static av_cold void rv10_init_static(void)
 rv_dc_chrom.table[(0x1FE << (DC_VLC_BITS - 9)) + i].sym = 255;
 rv_dc_chrom.table[(0x1FE << (DC_VLC_BITS - 9)) + i].len = 18;
 }
-ff_h263_decode_init_vlc();
 }
 
 static av_cold int rv10_decode_init(AVCodecContext *avctx)
@@ -364,16 +363,12 @@ static av_cold int rv10_decode_init(AVCodecContext *avctx)
avctx->coded_height, 0, avctx)) < 0)
 return ret;
 
-ret = ff_mpv_decode_init(s, avctx);
+ret = ff_h263_decode_init(avctx);
 if (ret < 0)
 return ret;
 
-s->out_format  = FMT_H263;
-
-rv->orig_width  =
-s->width= avctx->coded_width;
-rv->orig_height =
-s->height   = avctx->coded_height;
+rv->orig_width  = avctx->coded_width;
+rv->orig_height = avctx->coded_height;
 
 s->h263_long_vectors = ((uint8_t *) avctx->extradata)[3] & 1;
 rv->sub_id   = AV_RB32((uint8_t *) avctx->extradata + 4);
@@ -382,7 +377,6 @@ static av_cold int rv10_decode_init(AVCodecContext *avctx)
 minor_ver = RV_GET_MINOR_VER(rv->sub_id);
 micro_ver = RV_GET_MICRO_VER(rv->sub_id);
 
-s->low_delay = 1;
 switch (major_ver) {
 case 1:
 s->rv10_version = micro_ver ? 3 : 1;
@@ -405,13 +399,6 @@ static av_cold int rv10_decode_init(AVCodecContext *avctx)
((uint32_t *) avctx->extradata)[0]);
 }
 
-avctx->pix_fmt = AV_PIX_FMT_YUV420P;
-
-if ((ret = ff_mpv_common_init(s)) < 0)
-return ret;
-
-ff_h263dsp_init(&s->h263dsp);
-
 /* init static VLCs */
 ff_thread_once(&init_static_once, rv10_init_static);
 
-- 
2.40.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 65/67] avcodec/mpegvideo: Move quant_precision to Mpeg4DecContext

[Andreas Rheinhardt]

It is an MPEG-4-only value; it is always five for the MPEG-4
encoder, so just hardcode this value and move the MpegEncContext
field to Mpeg4DecContext.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c   |  1 -
 libavcodec/mpeg4video_parser.c |  2 +-
 libavcodec/mpeg4videodec.c | 20 ++--
 libavcodec/mpeg4videodec.h |  2 ++
 libavcodec/mpeg4videoenc.c |  2 +-
 libavcodec/mpegvideo.h |  1 -
 libavcodec/mpegvideo_enc.c |  2 --
 libavcodec/vaapi_mpeg4.c   |  2 +-
 8 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index 19a57582ad..a81786479d 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -99,7 +99,6 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 if (ret < 0)
 return ret;
 
-s->quant_precision = 5;
 s->decode_mb   = ff_h263_decode_mb;
 s->low_delay   = 1;
 
diff --git a/libavcodec/mpeg4video_parser.c b/libavcodec/mpeg4video_parser.c
index 402594e01d..b00b523bde 100644
--- a/libavcodec/mpeg4video_parser.c
+++ b/libavcodec/mpeg4video_parser.c
@@ -122,7 +122,7 @@ static av_cold int 
mpeg4video_parse_init(AVCodecParserContext *s)
 struct Mp4vParseContext *pc = s->priv_data;
 
 pc->first_picture   = 1;
-pc->dec_ctx.m.quant_precision = 5;
+pc->dec_ctx.quant_precision   = 5;
 pc->dec_ctx.m.slice_context_count = 1;
 pc->dec_ctx.showed_packed_warning = 1;
 return 0;
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 77bd3e9947..debcafc4c0 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -728,7 +728,7 @@ int ff_mpeg4_decode_video_packet_header(Mpeg4DecContext 
*ctx)
 s->mb_y = mb_num / s->mb_width;
 
 if (ctx->shape != BIN_ONLY_SHAPE) {
-int qscale = get_bits(&s->gb, s->quant_precision);
+int qscale = get_bits(&s->gb, ctx->quant_precision);
 if (qscale)
 s->chroma_qscale = s->qscale = qscale;
 }
@@ -2706,17 +2706,16 @@ static int decode_vol_header(Mpeg4DecContext *ctx, 
GetBitContext *gb)
 // FIXME sadct disable bit if verid!=1 && shape not rect
 
 if (get_bits1(gb) == 1) {   /* not_8_bit */
-s->quant_precision = get_bits(gb, 4);   /* quant_precision */
+ctx->quant_precision = get_bits(gb, 4); /* quant_precision */
 if (get_bits(gb, 4) != 8)   /* bits_per_pixel */
 av_log(s->avctx, AV_LOG_ERROR, "N-bit not supported\n");
-if (s->quant_precision != 5)
+if (ctx->quant_precision != 5)
 av_log(s->avctx, AV_LOG_ERROR,
-   "quant precision %d\n", s->quant_precision);
-if (s->quant_precision<3 || s->quant_precision>9) {
-s->quant_precision = 5;
-}
+   "quant precision %d\n", ctx->quant_precision);
+if (ctx->quant_precision < 3 || ctx->quant_precision > 9)
+ctx->quant_precision = 5;
 } else {
-s->quant_precision = 5;
+ctx->quant_precision = 5;
 }
 
 // FIXME a bunch of grayscale shape things
@@ -2904,7 +2903,7 @@ no_cplx_est:
 av_log(s->avctx, AV_LOG_DEBUG, "tb %d/%d, tincrbits:%d, qp_prec:%d, 
ps:%d, low_delay:%d  %s%s%s%s\n",
s->avctx->framerate.den, s->avctx->framerate.num,
ctx->time_increment_bits,
-   s->quant_precision,
+   ctx->quant_precision,
s->progressive_sequence,
s->low_delay,
ctx->scalability ? "scalability " :"" , s->quarter_sample ? 
"qpel " : "",
@@ -3286,7 +3285,7 @@ static int decode_vop_header(Mpeg4DecContext *ctx, 
GetBitContext *gb,
 }
 
 if (ctx->shape != BIN_ONLY_SHAPE) {
-s->chroma_qscale = s->qscale = get_bits(gb, s->quant_precision);
+s->chroma_qscale = s->qscale = get_bits(gb, ctx->quant_precision);
 if (s->qscale == 0) {
 av_log(s->avctx, AV_LOG_ERROR,
"Error, header damaged or not MPEG-4 header (qscale=0)\n");
@@ -3798,6 +3797,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 s->low_delay = 0; /* default, might be overridden in the vol header during 
header parsing */
 s->decode_mb = mpeg4_decode_mb;
 ctx->time_increment_bits = 4; /* default value for broken headers */
+ctx->quant_precision = 5;
 
 avctx->chroma_sample_location = AVCHROMA_LOC_LEFT;
 
diff --git a/libavcodec/mpeg4videodec.h b/libavcodec/mpeg4videodec.h
index 4a26d18987..734237b16f 100644
--- a/libavcodec/mpeg4videodec.h
+++ b/libavcodec/mpeg4videodec.h
@@ -60,6 +60,8 @@ typedef struct Mpeg4DecContext {
 int enhancement_type;
 int scalability;
 
+int quant_precision;
+
 /// QP above which the ac VLC should be used for intra dc
 int intra_dc_threshold;
 
diff --git a/libavcodec/mpeg4videoenc.c b/libavco

[FFmpeg-devel] [PATCH 66/67] avcodec/rv10: Avoid indirection

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/rv10.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/rv10.c b/libavcodec/rv10.c
index 65060d4ece..753c6c6cb3 100644
--- a/libavcodec/rv10.c
+++ b/libavcodec/rv10.c
@@ -385,11 +385,11 @@ static av_cold int rv10_decode_init(AVCodecContext *avctx)
 case 2:
 if (minor_ver >= 2) {
 s->low_delay   = 0;
-s->avctx->has_b_frames = 1;
+avctx->has_b_frames = 1;
 }
 break;
 default:
-av_log(s->avctx, AV_LOG_ERROR, "unknown header %X\n", rv->sub_id);
+av_log(avctx, AV_LOG_ERROR, "unknown header %X\n", rv->sub_id);
 avpriv_request_sample(avctx, "RV1/2 version");
 return AVERROR_PATCHWELCOME;
 }
-- 
2.40.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 67/67] avcodec/mpegvideo_dec: Move setting dct_unquant funcs to h263dec.c

[Andreas Rheinhardt]

It is a better place for it; no non-h263-based decoder needs
these functions any more (both H.261 and the error resilience
code recently stopped doing so).

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/h263dec.c   | 5 +
 libavcodec/mpegvideo_dec.c | 6 --
 2 files changed, 5 insertions(+), 6 deletions(-)

diff --git a/libavcodec/h263dec.c b/libavcodec/h263dec.c
index a81786479d..0c23012584 100644
--- a/libavcodec/h263dec.c
+++ b/libavcodec/h263dec.c
@@ -102,6 +102,11 @@ av_cold int ff_h263_decode_init(AVCodecContext *avctx)
 s->decode_mb   = ff_h263_decode_mb;
 s->low_delay   = 1;
 
+// dct_unquantize defaults for H.263;
+// they might change on a per-frame basis for MPEG-4.
+s->dct_unquantize_intra = s->dct_unquantize_h263_intra;
+s->dct_unquantize_inter = s->dct_unquantize_h263_inter;
+
 /* select sub codec */
 switch (avctx->codec->id) {
 case AV_CODEC_ID_H263:
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index da88a35120..1cab108935 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -60,12 +60,6 @@ int ff_mpv_decode_init(MpegEncContext *s, AVCodecContext 
*avctx)
 
 ff_mpv_idct_init(s);
 
-// dct_unquantize defaults for H.261 and H.263;
-// they might change on a per-frame basis for MPEG-4.
-// Unused by the MPEG-1/2 decoders.
-s->dct_unquantize_intra = s->dct_unquantize_h263_intra;
-s->dct_unquantize_inter = s->dct_unquantize_h263_inter;
-
 ff_h264chroma_init(&s->h264chroma, 8); //for lowres
 
 if (s->picture_pool)  // VC-1 can call this multiple times
-- 
2.40.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] rtp enc/dec update for vvc

[Frank Plowman]

Hi,

Thanks for the patch.  Unfortunately it looks to be corrupted and does
not apply.  Also, it looks as though you submitted five near-identical
patches.  I would suggest you try directing patches to your own mailbox
and re-applying them while debugging the formatting issues, rather than
sending lots of corrupted patches to the ML.

A couple more comments inline.

Cheers,
Frank

On 14/06/2024 03:35, ftaft2000 wrote:
> Signed-off-by: ftaft2000 
> ---
>  .gitignore |   1 +
>  configure  |   4 +
>  libavcodec/Makefile    |   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libvvenc.c  | 566 +
>  libavformat/Makefile   |   1 +
>  libavformat/rtpdec.c   |   1 +
>  libavformat/rtpdec_formats.h   |   1 +
>  libavformat/rtpdec_vvc.c   | 349 
>  libavformat/rtpenc.c   |   2 +
>  libavformat/rtpenc_h264_hevc.c |  94 +-
>  libavformat/sdp.c  | 182 +++
>  12 files changed, 1197 insertions(+), 6 deletions(-)
>  create mode 100644 libavcodec/libvvenc.c
>  create mode 100644 libavformat/rtpdec_vvc.c
> 
> diff --git a/.gitignore b/.gitignore
> index e810d11107..d7441a6cdc 100644
> --- a/.gitignore
> +++ b/.gitignore
> @@ -41,3 +41,4 @@
>  /src
>  /mapfile
>  /tools/python/__pycache__/
> +/build

I don't think this should be here - this is specific to your
environment.  If you want to ignore something locally, you can use
.git/info/exclude

> \ No newline at end of file
> diff --git a/configure b/configure
> index 83284427df..d331688eb4 100755
> --- a/configure
> +++ b/configure
> @@ -296,6 +296,7 @@ External library support:
>    --enable-libwebp enable WebP encoding via libwebp [no]
>    --enable-libx264 enable H.264 encoding via x264 [no]
>    --enable-libx265 enable HEVC encoding via x265 [no]
> +  --enable-libvvenc    enable H.266/VVC encoding via vvenc [no]

This looks like you had the VVenC patchset applied when you created this
commit.  If your patch depends on the VVenC patchset, it will have to
wait until that is applied (which could well be in the next day or two).

>    --enable-libxeve enable EVC encoding via libxeve [no]
>    --enable-libxevd enable EVC decoding via libxevd [no]
>    --enable-libxavs enable AVS encoding via xavs [no]
> @@ -1867,6 +1868,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
>  libvidstab
>  libx264
>  libx265
> +    libvvenc
>  libxavs
>  libxavs2
>  libxvid
> @@ -3569,6 +3571,7 @@ libx264rgb_encoder_deps="libx264"
>  libx264rgb_encoder_select="libx264_encoder"
>  libx265_encoder_deps="libx265"
>  libx265_encoder_select="atsc_a53 dovi_rpuenc"
> +libvvenc_encoder_deps="libvvenc"
>  libxavs_encoder_deps="libxavs"
>  libxavs2_encoder_deps="libxavs2"
>  libxevd_decoder_deps="libxevd"
> @@ -7041,6 +7044,7 @@ enabled libx264   && require_pkg_config
> libx264 x264 "stdint.h x264.h" x
>   check_cpp_condition libx262 x264.h
> "X264_MPEG2"
>  enabled libx265   && require_pkg_config libx265 x265 x265.h
> x265_api_get &&
>   require_cpp_condition libx265 x265.h
> "X265_BUILD >= 89"
> +enabled libvvenc  && require_pkg_config libvvenc "libvvenc >=
> 1.6.1" "vvenc/vvenc.h" vvenc_get_version
>  enabled libxavs   && require libxavs "stdint.h xavs.h"
> xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
>  enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >=
> 1.3.0" "stdint.h xavs2.h" xavs2_api_get
>  enabled libxevd   && require_pkg_config libxevd "xevd >= 0.4.1"
> "xevd.h" xevd_decode
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 1a44352906..2e98e1c72f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1155,6 +1155,7 @@ OBJS-$(CONFIG_LIBWEBP_ANIM_ENCODER)   +=
> libwebpenc_common.o libwebpenc_anim
>  OBJS-$(CONFIG_LIBX262_ENCODER)    += libx264.o
>  OBJS-$(CONFIG_LIBX264_ENCODER)    += libx264.o
>  OBJS-$(CONFIG_LIBX265_ENCODER)    += libx265.o
> +OBJS-$(CONFIG_LIBVVENC_ENCODER)   += libvvenc.o
>  OBJS-$(CONFIG_LIBXAVS_ENCODER)    += libxavs.o
>  OBJS-$(CONFIG_LIBXAVS2_ENCODER)   += libxavs2.o
>  OBJS-$(CONFIG_LIBXEVD_DECODER)    += libxevd.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b102a8069e..7650abebe4 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -807,6 +807,7 @@ extern const FFCodec ff_libx262_encoder;
>  extern const FFCodec ff_libx264_encoder;
>  extern const FFCodec ff_libx264rgb_encoder;
>  extern FFCodec ff_libx265_encoder;
> +extern const FFCodec ff_libvvenc_encoder;
>  extern const FFCodec ff_libxeve_encoder;
>  extern const FFCodec ff_libxevd_decoder;
>  extern const FFCodec ff_libxavs_encoder;
> diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
> new file mode 100644
> inde

Re: [FFmpeg-devel] [PATCH 2/4] lavc/mpegvideo: use H263DSP dequant function

[Rémi Denis-Courmont]

Le perjantaina 14. kesäkuuta 2024, 18.41.48 EEST James Almer a écrit :
> On 6/14/2024 12:11 PM, Rémi Denis-Courmont wrote:
> > Le perjantaina 14. kesäkuuta 2024, 17.45.50 EEST Rémi Denis-Courmont a 
écrit :
> >> And x86 only has MMX.
> > 
> > And the x86 code uses inline assembler. That's not viable on any ISA with
> > sane conventions such as Arm or RISC-V. The compiler will reject our
> > vector clobbers, unless the Vector extension is included in the
> > compilation target. But then that breaks run-time detection, and will be
> > rejected by all Linux distros.
> 
> I was thinking on removing that inline version and probably replacing it
> with sse2, using the dsp prototypes you introduce in this set.

I saw that, but we can't have the cake and eat it. Those DSP callbacks can't 
exist without adding a layer of indirection.

-- 
雷米‧德尼-库尔蒙
http://www.remlab.net/



___
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 5.1.5 and 4.3.7

[Michael Niedermayer]

On Thu, Jun 13, 2024 at 10:41:19PM +0200, Michael Niedermayer wrote:
> On Thu, Jun 13, 2024 at 12:14:54PM +0200, Michael Niedermayer wrote:
> > Hi all
> > 
> > I intend to make 5.1.5 and 4.3.7 releases "soon"(1) for debian
> > 
> > If you want something backported, now is your last chance to backport it
> > 
> > thx
> > 
> > (1) i still have more things to backport and somethings i need to fix in
> > my local setup, so it will take me a few days probably
> 
> i intend to do the 5.1.5 release tomorrow

last chance is now to backport your fixes to 5.1.5 (unless something unexpected 
happens)

i intend to do 4.3.7 tomorrow

[]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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] avr32: remove explicit support

[Tomas Härdin]

sön 2024-06-09 klockan 14:55 +0300 skrev Rémi Denis-Courmont:
> The vendor has long since switched to Arm, wit the last product
> reaching
> their official end-of-life over 11 years ago. Linux support for the
> ISA
> was dropped 7 years ago. More importantly, this architecture was
> never
> supported by upstream GCC, and the vendor fork is stuck at version
> 4.2,
> which FFmpeg no longer supports (as per C11 requirement).
> 
> Presumably, this is still the case given the lack of vendor support.
> Indeed all of the code being removed here consisted of inline
> assembler
> scalar optimisations. A sane C compiler should be able to perform
> those
> automatically nowadays (with the sole exception of fast CLZ
> detection),
> but this is moot as this architecture is evidently dead.
> ---
>  configure  |  26 +
>  libavcodec/avr32/mathops.h | 101 --
>  libavcodec/mathops.h   |   2 -
>  libavutil/avr32/bswap.h    |  44 
>  libavutil/avr32/intreadwrite.h | 182 ---
> --
>  libavutil/bswap.h  |   2 -
>  libavutil/intreadwrite.h   |   2 -
>  7 files changed, 1 insertion(+), 358 deletions(-)
>  delete mode 100644 libavcodec/avr32/mathops.h
>  delete mode 100644 libavutil/avr32/bswap.h
>  delete mode 100644 libavutil/avr32/intreadwrite.h

Sounds good to me

/Tomas
___
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] movenc: Add an option for hiding fragments at the end

[Dennis Sädtler via ffmpeg-devel]

On 2024-06-14 13:23, Gyan Doshi wrote:



On 2024-06-14 04:35 pm, Timo Rothenpieler wrote:

On 14/06/2024 12:44, Martin Storsjö wrote:

On Fri, 14 Jun 2024, Gyan Doshi wrote:


On 2024-06-14 02:18 am, Martin Storsjö wrote:

On Thu, 13 Jun 2024, Gyan Doshi wrote:


On 2024-06-13 06:20 pm, Martin Storsjö wrote:


I'd otherwise want to push this, but I'm not entirely satisfied 
with the option name quite yet. I'm pondering if we should call 
it "hybrid_fragmented" - any opinions, Dennis or Timo?


How about `resilient_mode` or `recoverable`?
I agree that the how is secondary.


Those are good suggestions as well - but I think I prefer 
"hybrid_fragmented" still.


In theory, I guess one could implement resilient writing in a 
number of different ways, whereas the hybrid 
fragmented/non-fragmented only is one.


So with a couple other voices agreeing with the name 
"hybrid_fragmented", I'll post a new patch with the option in that 
form - hopefully you don't object to it.


The term hybrid is not applicable here. The fragmented state is 
transient during writing and contingent in the finished artifact 
depending on how the writing process concluded.
Hybrid implies both modes available e.g.. a hybrid vehicle can use 
both types of energy sources. The artifact here will be one _or_ 
the other.


Sure, the file itself is either or, but the process of writing will 
have utilized both. TBH, I don't see it as such a black-or-white thing.


What do the others who have chimed in on the thread think, compared 
to calling it "recoverable" or "resilient_mode"?


I don't have a super strong opinion on it, but out of the options 
provided, I'd prefer the hybrid_ one, since there's a good chance 
it'll become an established term now that OBS presents it quite 
publicly visible.


The OBS dev intends to change the term:

"Come up with a better name than "Hybrid MP4" that hopefully won't 
confuse users"
https://github.com/obsproject/obs-studio/pull/10608#issuecomment-2095222024 



Regards,
Gyan


Now that it's merged and in the hands of users I don't have any 
intention of changing the name any more.
We had some chats about about it, but nobody suggested anything that 
people agreed was better, so it stuck.


While "resilient" certainly fits, it could equally apply to regular 
fragmented MP4 (e.g. vMix uses that terminology for fMP4 if I'm not 
mistaken).
The important attribute with this approach is that it's resilient *and* 
compatible, and I'm still not sure how to get that across in name alone.


Obviously FFmpeg has a different target demographic and can use 
something different than OBS, "Hybrid MP4" is just what I came up with 
as user-facing name for the feature at the time.


~Dennis

___
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 16/17] avdevice/dshow: Initialize 2 pointers

[Roger Pack]

On Sun, Jun 2, 2024 at 12:58 PM Michael Niedermayer
 wrote:
>
> On Mon, May 27, 2024 at 01:52:28AM +0200, Michael Niedermayer wrote:
> > Coverity claims these are used uninitilaized in CID1598561 Uninitialized 
> > pointer write and CID1598565 Uninitialized pointer write
> >
> > Sponsored-by: Sovereign Tech Fund
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavdevice/dshow.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
>
> will apply

They seemed to LGTM.
___
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/2] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers

[Osamu Watanabe]

Signed-off-by: Osamu Watanabe 
---
 libavcodec/jpeg2000.h  |  10 +
 libavcodec/jpeg2000dec.c   | 454 ++---
 libavcodec/jpeg2000dec.h   |   7 +
 libavcodec/jpeg2000htdec.c | 225 ++
 libavcodec/jpeg2000htdec.h |   2 +-
 5 files changed, 518 insertions(+), 180 deletions(-)

diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
index d004c08f10..93221d90ca 100644
--- a/libavcodec/jpeg2000.h
+++ b/libavcodec/jpeg2000.h
@@ -37,12 +37,14 @@
 
 enum Jpeg2000Markers {
 JPEG2000_SOC = 0xff4f, // start of codestream
+JPEG2000_CAP = 0xff50, // extended capabilities
 JPEG2000_SIZ = 0xff51, // image and tile size
 JPEG2000_COD,  // coding style default
 JPEG2000_COC,  // coding style component
 JPEG2000_TLM = 0xff55, // tile-part length, main header
 JPEG2000_PLM = 0xff57, // packet length, main header
 JPEG2000_PLT,  // packet length, tile-part header
+JPEG2000_CPF,  // corresponding profile
 JPEG2000_QCD = 0xff5c, // quantization default
 JPEG2000_QCC,  // quantization component
 JPEG2000_RGN,  // region of interest
@@ -58,6 +60,12 @@ enum Jpeg2000Markers {
 JPEG2000_EOC = 0xffd9, // end of codestream
 };
 
+enum JPEG2000_Ccap15_b14_15_params {
+HTJ2K_HTONLY = 0,  // HTONLY, bit 14 and 15 are 0
+HTJ2K_HTDECLARED,  // HTDECLARED, bit 14 = 1 and bit 15 = 0
+HTJ2K_MIXED = 3,   // MIXED, bit 14 and 15 are 1
+};
+
 #define JPEG2000_SOP_FIXED_BYTES 0xFF910004
 #define JPEG2000_SOP_BYTE_LENGTH 6
 
@@ -192,6 +200,8 @@ typedef struct Jpeg2000Cblk {
 /* specific to HT code-blocks */
 int zbp;
 int pass_lengths[2];
+uint8_t modes; // copy of SPcod/SPcoc field to parse HT-MIXED mode
+uint8_t ht_plhd; // are we looking for HT placeholder passes?
 } Jpeg2000Cblk; // code block
 
 typedef struct Jpeg2000Prec {
diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index d15502a527..d299c67cc7 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -54,6 +54,15 @@
 #define HAD_COC 0x01
 #define HAD_QCC 0x02
 
+// Values of flag for placeholder passes
+enum HT_PLHD_STATUS {
+HT_PLHD_OFF,
+HT_PLHD_ON
+};
+
+#define HT_MIXED 0x80 // bit 7 of SPcod/SPcoc
+
+
 /* get_bits functions for JPEG2000 packet bitstream
  * It is a get_bit function with a bit-stuffing routine. If the value of the
  * byte is 0xFF, the next byte includes an extra zero bit stuffed into the MSB.
@@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
 } else if (ncomponents == 1 && s->precision == 8) {
 s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
 i = 0;
+} else if (ncomponents == 1 && s->precision == 12) {
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+i = 0;
 }
 }
 
@@ -408,6 +420,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
 s->avctx->bits_per_raw_sample = s->precision;
 return 0;
 }
+/* get extended capabilities (CAP) marker segment */
+static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
+{
+uint32_t Pcap;
+uint16_t Ccap_i[32] = { 0 };
+uint16_t Ccap_15;
+uint8_t P;
+
+if (bytestream2_get_bytes_left(&s->g) < 6) {
+av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for CAP\n");
+return AVERROR_INVALIDDATA;
+}
+
+Pcap = bytestream2_get_be32u(&s->g);
+s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
+for (int i = 0; i < 32; i++) {
+if ((Pcap >> (31 - i)) & 1)
+Ccap_i[i] = bytestream2_get_be16u(&s->g);
+}
+Ccap_15 = Ccap_i[14];
+if (s->isHT == 1) {
+av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
+// Bits 14-15
+switch ((Ccap_15 >> 14) & 0x3) {
+case 0x3:
+s->Ccap15_b14_15 = HTJ2K_MIXED;
+break;
+case 0x1:
+s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
+break;
+case 0x0:
+s->Ccap15_b14_15 = HTJ2K_HTONLY;
+break;
+default:
+av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap value.\n");
+return AVERROR(EINVAL);
+break;
+}
+// Bit 13
+if ((Ccap_15 >> 13) & 1) {
+av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not supported.\n");
+return AVERROR_PATCHWELCOME;
+}
+// Bit 12
+s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
+// Bit 11
+s->Ccap15_b11 = (Ccap_15 >> 11) & 1;
+// Bit 5
+s->Ccap15_b05 = (Ccap_15 >> 5) & 1;
+// Bit 0-4
+P = Ccap_15 & 0x1F;
+if (!P)
+s->HT_MAGB = 8;
+else if (P < 20)
+s->HT_MAGB = P + 8;
+else if (P < 31)
+s->HT_MAGB = 4 * (P - 19) + 27;
+else
+s->HT_MAGB = 74;
+
+if (s->HT_MAGB > 31) {
+av_log(s->avctx, AV_LOG_ERROR, "Available internal precision is 
exceeded (MAGB> 31).\n");
+return AVERROR_PATCHWELCOME;
+}
+}
+return 0;
+}
 
 /* get common part

[FFmpeg-devel] [PATCH 2/2] avcodec/jpeg2000dec: fix tilepart processing

[Osamu Watanabe]

This is the same as 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240607002549.2259139-1-owata...@es.takushoku-u.ac.jp/

Signed-off-by: Osamu Watanabe 
---
 libavcodec/jpeg2000dec.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
index d299c67cc7..395cf34bcd 100644
--- a/libavcodec/jpeg2000dec.c
+++ b/libavcodec/jpeg2000dec.c
@@ -1097,6 +1097,7 @@ static inline void select_header(Jpeg2000DecoderContext 
*s, const Jpeg2000Tile *
 {
 s->g = tile->tile_part[*tp_index].header_tpg;
 if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
+av_log(s->avctx, AV_LOG_WARNING, "Packet header bytes in PPM marker 
segment is too short.\n");
 if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
 s->g = tile->tile_part[++(*tp_index)].tpg;
 }
@@ -1106,10 +1107,18 @@ static inline void select_header(Jpeg2000DecoderContext 
*s, const Jpeg2000Tile *
 static inline void select_stream(Jpeg2000DecoderContext *s, const Jpeg2000Tile 
*tile,
  int *tp_index, const Jpeg2000CodingStyle 
*codsty)
 {
+int32_t is_endof_tp;
+
 s->g = tile->tile_part[*tp_index].tpg;
-if (bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8) {
+is_endof_tp = bytestream2_get_bytes_left(&s->g) == 0 && s->bit_index == 8;
+// Following while loop is necessary because a tilepart may include only 
SOD marker.
+// Such a tilepart has neither packet header nor compressed data.
+while (is_endof_tp) {
 if (*tp_index < FF_ARRAY_ELEMS(tile->tile_part) - 1) {
 s->g = tile->tile_part[++(*tp_index)].tpg;
+is_endof_tp = bytestream2_get_bytes_left(&s->g) == 0 && 
s->bit_index == 8;
+} else {
+is_endof_tp = 0;
 }
 }
 if (codsty->csty & JPEG2000_CSTY_SOP) {
-- 
2.34.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/aeadec, avcodec/atrac1: Fix 8 and 4-channel ATRAC1 support

[asivery via ffmpeg-devel]

Right now both the ATRAC1 decoder implementation, and the AEA demuxer don't 
accept 4-track and 8-track ATRAC data. This patch fixes that problem.From c42e05855a018e28159bf29b49137bb33f5e45fd Mon Sep 17 00:00:00 2001
From: asivery 
Date: Sat, 15 Jun 2024 07:47:40 +0200
Subject: [PATCH] avformat/aeadec, avcodec/atrac1: Fix 8 and 4-channel ATRAC1 support

Signed-off-by: asivery 
---
 libavcodec/atrac1.c  | 12 ++--
 libavformat/aeadec.c |  2 +-
 2 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/libavcodec/atrac1.c b/libavcodec/atrac1.c
index cdcc7a669e..448bdfc7e9 100644
--- a/libavcodec/atrac1.c
+++ b/libavcodec/atrac1.c
@@ -49,7 +49,7 @@
 #define AT1_SU_SAMPLES   512///< number of samples in a sound unit
 #define AT1_FRAME_SIZE   AT1_SU_SIZE * 2
 #define AT1_SU_MAX_BITS  AT1_SU_SIZE * 8
-#define AT1_MAX_CHANNELS 2
+#define AT1_MAX_CHANNELS 8
 
 #define AT1_QMF_BANDS3
 #define IDX_LOW_BAND 0
@@ -339,7 +339,7 @@ static av_cold int atrac1_decode_init(AVCodecContext *avctx)
 AVFloatDSPContext *fdsp;
 int channels = avctx->ch_layout.nb_channels;
 float scale = -1.0 / (1 << 15);
-int ret;
+int ret, ch;
 
 avctx->sample_fmt = AV_SAMPLE_FMT_FLTP;
 
@@ -380,10 +380,10 @@ static av_cold int atrac1_decode_init(AVCodecContext *avctx)
 q->bands[2] = q->high;
 
 /* Prepare the mdct overlap buffers */
-q->SUs[0].spectrum[0] = q->SUs[0].spec1;
-q->SUs[0].spectrum[1] = q->SUs[0].spec2;
-q->SUs[1].spectrum[0] = q->SUs[1].spec1;
-q->SUs[1].spectrum[1] = q->SUs[1].spec2;
+for (ch = 0; ch < AT1_MAX_CHANNELS; ch++) {
+q->SUs[ch].spectrum[0] = q->SUs[ch].spec1;
+q->SUs[ch].spectrum[1] = q->SUs[ch].spec2;
+}
 
 return 0;
 }
diff --git a/libavformat/aeadec.c b/libavformat/aeadec.c
index be18e7b725..0a3d09a89d 100644
--- a/libavformat/aeadec.c
+++ b/libavformat/aeadec.c
@@ -84,7 +84,7 @@ static int aea_read_header(AVFormatContext *s)
 st->codecpar->sample_rate= 44100;
 st->codecpar->bit_rate   = 146000 * channels;
 
-if (channels != 1 && channels != 2) {
+if (channels < 1 || channels > 8) {
 av_log(s, AV_LOG_ERROR, "Channels %d not supported!\n", channels);
 return AVERROR_INVALIDDATA;
 }
-- 
2.34.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 1/2] avcodec/jpeg2000dec: Add support for placeholder passes, CAP, and CPF markers

[Pierre-Anthony Lemieux]

Hi Osamu,

Can you provide the list of J2K reference codestreams that this code
allows FFMPEG to support -- not including those already supported [1]?

[1] https://github.com/FFmpeg/FFmpeg/blob/master/tests/fate/jpeg2000.mak

Best,

-- Pierre

On Fri, Jun 14, 2024 at 8:15 PM Osamu Watanabe
 wrote:
>
> Signed-off-by: Osamu Watanabe 
> ---
>  libavcodec/jpeg2000.h  |  10 +
>  libavcodec/jpeg2000dec.c   | 454 ++---
>  libavcodec/jpeg2000dec.h   |   7 +
>  libavcodec/jpeg2000htdec.c | 225 ++
>  libavcodec/jpeg2000htdec.h |   2 +-
>  5 files changed, 518 insertions(+), 180 deletions(-)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index d004c08f10..93221d90ca 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -37,12 +37,14 @@
>
>  enum Jpeg2000Markers {
>  JPEG2000_SOC = 0xff4f, // start of codestream
> +JPEG2000_CAP = 0xff50, // extended capabilities
>  JPEG2000_SIZ = 0xff51, // image and tile size
>  JPEG2000_COD,  // coding style default
>  JPEG2000_COC,  // coding style component
>  JPEG2000_TLM = 0xff55, // tile-part length, main header
>  JPEG2000_PLM = 0xff57, // packet length, main header
>  JPEG2000_PLT,  // packet length, tile-part header
> +JPEG2000_CPF,  // corresponding profile
>  JPEG2000_QCD = 0xff5c, // quantization default
>  JPEG2000_QCC,  // quantization component
>  JPEG2000_RGN,  // region of interest
> @@ -58,6 +60,12 @@ enum Jpeg2000Markers {
>  JPEG2000_EOC = 0xffd9, // end of codestream
>  };
>
> +enum JPEG2000_Ccap15_b14_15_params {
> +HTJ2K_HTONLY = 0,  // HTONLY, bit 14 and 15 are 0
> +HTJ2K_HTDECLARED,  // HTDECLARED, bit 14 = 1 and bit 15 = 0
> +HTJ2K_MIXED = 3,   // MIXED, bit 14 and 15 are 1
> +};
> +
>  #define JPEG2000_SOP_FIXED_BYTES 0xFF910004
>  #define JPEG2000_SOP_BYTE_LENGTH 6
>
> @@ -192,6 +200,8 @@ typedef struct Jpeg2000Cblk {
>  /* specific to HT code-blocks */
>  int zbp;
>  int pass_lengths[2];
> +uint8_t modes; // copy of SPcod/SPcoc field to parse HT-MIXED mode
> +uint8_t ht_plhd; // are we looking for HT placeholder passes?
>  } Jpeg2000Cblk; // code block
>
>  typedef struct Jpeg2000Prec {
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index d15502a527..d299c67cc7 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -54,6 +54,15 @@
>  #define HAD_COC 0x01
>  #define HAD_QCC 0x02
>
> +// Values of flag for placeholder passes
> +enum HT_PLHD_STATUS {
> +HT_PLHD_OFF,
> +HT_PLHD_ON
> +};
> +
> +#define HT_MIXED 0x80 // bit 7 of SPcod/SPcoc
> +
> +
>  /* get_bits functions for JPEG2000 packet bitstream
>   * It is a get_bit function with a bit-stuffing routine. If the value of the
>   * byte is 0xFF, the next byte includes an extra zero bit stuffed into the 
> MSB.
> @@ -382,6 +391,9 @@ static int get_siz(Jpeg2000DecoderContext *s)
>  } else if (ncomponents == 1 && s->precision == 8) {
>  s->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
>  i = 0;
> +} else if (ncomponents == 1 && s->precision == 12) {
> +s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
> +i = 0;
>  }
>  }
>
> @@ -408,6 +420,73 @@ static int get_siz(Jpeg2000DecoderContext *s)
>  s->avctx->bits_per_raw_sample = s->precision;
>  return 0;
>  }
> +/* get extended capabilities (CAP) marker segment */
> +static int get_cap(Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c)
> +{
> +uint32_t Pcap;
> +uint16_t Ccap_i[32] = { 0 };
> +uint16_t Ccap_15;
> +uint8_t P;
> +
> +if (bytestream2_get_bytes_left(&s->g) < 6) {
> +av_log(s->avctx, AV_LOG_ERROR, "Insufficient space for CAP\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +Pcap = bytestream2_get_be32u(&s->g);
> +s->isHT = (Pcap >> (31 - (15 - 1))) & 1;
> +for (int i = 0; i < 32; i++) {
> +if ((Pcap >> (31 - i)) & 1)
> +Ccap_i[i] = bytestream2_get_be16u(&s->g);
> +}
> +Ccap_15 = Ccap_i[14];
> +if (s->isHT == 1) {
> +av_log(s->avctx, AV_LOG_INFO, "This is an HTJ2K codestream.\n");
> +// Bits 14-15
> +switch ((Ccap_15 >> 14) & 0x3) {
> +case 0x3:
> +s->Ccap15_b14_15 = HTJ2K_MIXED;
> +break;
> +case 0x1:
> +s->Ccap15_b14_15 = HTJ2K_HTDECLARED;
> +break;
> +case 0x0:
> +s->Ccap15_b14_15 = HTJ2K_HTONLY;
> +break;
> +default:
> +av_log(s->avctx, AV_LOG_ERROR, "Unknown CCap value.\n");
> +return AVERROR(EINVAL);
> +break;
> +}
> +// Bit 13
> +if ((Ccap_15 >> 13) & 1) {
> +av_log(s->avctx, AV_LOG_ERROR, "MULTIHT set is not supported.\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +// Bit 12
> +s->Ccap15_b12 = (Ccap_15 >> 12) & 1;
> +// Bit 11

Re: [FFmpeg-devel] [PATCH] lavc/vvc: Invalidate PPSs which refer to a changed SPS

[Christophe Gisquet]

Le ven. 14 juin 2024, 11:39, Frank Plowman  a écrit :

> When the SPS associated with a particular SPS ID changes, invalidate all
> the PPSs which use that SPS ID.  Fixes crashes with illegal bitstreams.
> This is done in the CBS, rather than in libavcodec/vvc/ps.c like the SPS
> ID reuse validation, as parts of the CBS parsing process for PPSs
> depend on the SPS being referred to.
>

I am uncertain about this. I have no definite knowledge nor proof, but I
would have thought these are persistent, IE it's legal to update some of
them, their validity depending on something else.

Wondering if the tested streams are thus conformant.

But I don't know the actual rule. Maybe finding an EOB/EOS NUT? Related to
some particular shape of a clean random access point, that would require
retransmitting VPS/SPS/PPS/APS/... ?

Asking Benjamin Bross might be a better option here.

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