Re: [FFmpeg-devel] [PATCH v2] vulkan_hevc: use diagonal scan order for scaling lists
Jul 28, 2023, 03:21 by b...@bcheng.me: > The hevc parser parses the diagonal scan order in bitstream into raster > scan order. However, the Vulkan spec wants it as specified in H265 spec, > which is diagonal scan order. > > Tested on RADV. > > v2: fix copy-paste typo with PPS. > Pushed with a minor cosmetic fix Thanks ___ 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] looking to hire expert for a short project: lossless screen and sound capture 4k@60hz
Hi all, I've been directed here from https://ffmpeg.org/consulting.html as I'm looking to hire an expert for what should hopefully be a simple but well-paid job. Please let me know if anyone has availability! What I'm trying to do is capture demoscene demos in full quality: 4k@60hz (with sound of course). My rig is presentable: nvidia A6000 and 192G RAM. I am a software engineer, but don't know very much about video processing or ffmpeg. I tried: ffmpeg -filter_complex ddagrab=0,hwdownload,format=bgra,framerate=60 -c:v utvideo output.mkv What happened: the first minute or so (always roughly the same length of time) is captured fine. Then it drops off the cliff, something like 1 frame per 3 seconds, but also trying to interpolate between them, so it looks really weird. I was not able to get ffmpeg to report to me any dropped frames which is upsetting and worrying. I also don't understand where the interpolation comes from and would love to turn it off. I can't think of a reason for the droppage: my RAM is big enough to hold the full video (about 50G total). My only theory is that GPU memory might be getting full (will check tomorrow), but I'd expect hwdownload rates to not be that slow. Maybe I should use hevc_nvenc with lossless setting, but there's some talk about the yuv420 conversion being not lossless... Anyway, would really appreciate someone educating me on these and would happily pay for your time! Best, Misha ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 4/4] all: Guard if (EXTERNAL*) checks with #if HAVE_X86ASM
Continuation of 40e6575aa3eed64cd32bf28c00ae57edc5acb25a
Signed-off-by: L. E. Segovia
---
libavcodec/x86/aacencdsp_init.c| 2 ++
libavcodec/x86/aacpsdsp_init.c | 2 ++
libavcodec/x86/ac3dsp_init.c | 4
libavcodec/x86/audiodsp_init.c | 2 ++
libavcodec/x86/bswapdsp_init.c | 2 ++
libavcodec/x86/cavsdsp.c | 2 ++
libavcodec/x86/celt_pvq_init.c | 2 ++
libavcodec/x86/cfhddsp_init.c | 2 ++
libavcodec/x86/cfhdencdsp_init.c | 2 ++
libavcodec/x86/dcadsp_init.c | 2 ++
libavcodec/x86/dct_init.c | 2 ++
libavcodec/x86/dnxhdenc_init.c | 2 ++
libavcodec/x86/exrdsp_init.c | 2 ++
libavcodec/x86/fft_init.c | 2 ++
libavcodec/x86/g722dsp_init.c | 2 ++
libavcodec/x86/h263dsp_init.c | 2 ++
libavcodec/x86/h264_intrapred_init.c | 2 ++
libavcodec/x86/h264chroma_init.c | 2 ++
libavcodec/x86/hevcdsp_init.c | 2 ++
libavcodec/x86/hpeldsp_init.c | 2 ++
libavcodec/x86/hpeldsp_vp3_init.c | 2 ++
libavcodec/x86/huffyuvdsp_init.c | 2 ++
libavcodec/x86/huffyuvencdsp_init.c| 2 ++
libavcodec/x86/idctdsp_init.c | 2 ++
libavcodec/x86/jpeg2000dsp_init.c | 2 ++
libavcodec/x86/lossless_videodsp_init.c| 2 ++
libavcodec/x86/lossless_videoencdsp_init.c | 2 ++
libavcodec/x86/me_cmp_init.c | 2 ++
libavcodec/x86/mlpdsp_init.c | 2 +-
libavcodec/x86/mpegvideoencdsp_init.c | 2 ++
libavcodec/x86/opusdsp_init.c | 2 ++
libavcodec/x86/pixblockdsp_init.c | 2 ++
libavcodec/x86/pngdsp_init.c | 2 ++
libavcodec/x86/proresdsp_init.c| 2 ++
libavcodec/x86/rv34dsp_init.c | 2 ++
libavcodec/x86/sbcdsp_init.c | 2 ++
libavcodec/x86/sbrdsp_init.c | 2 ++
libavcodec/x86/svq1enc_init.c | 2 ++
libavcodec/x86/utvideodsp_init.c | 2 ++
libavcodec/x86/v210enc_init.c | 6 --
libavcodec/x86/vc1dsp_init.c | 2 +-
libavcodec/x86/vorbisdsp_init.c| 2 ++
libavcodec/x86/vp3dsp_init.c | 2 ++
libavcodec/x86/vp6dsp_init.c | 2 ++
libavfilter/x86/af_afir_init.c | 2 ++
libavfilter/x86/af_anlmdn_init.c | 2 ++
libavfilter/x86/af_volume_init.c | 2 ++
libavfilter/x86/avf_showcqt_init.c | 2 ++
libavfilter/x86/colorspacedsp_init.c | 2 ++
libavfilter/x86/vf_atadenoise_init.c | 2 ++
libavfilter/x86/vf_blend_init.c| 2 ++
libavfilter/x86/vf_bwdif_init.c| 2 ++
libavfilter/x86/vf_convolution_init.c | 2 +-
libavfilter/x86/vf_framerate_init.c| 2 ++
libavfilter/x86/vf_fspp_init.c | 2 ++
libavfilter/x86/vf_gblur_init.c| 2 ++
libavfilter/x86/vf_hflip_init.c| 2 ++
libavfilter/x86/vf_limiter_init.c | 2 ++
libavfilter/x86/vf_maskedclamp_init.c | 2 ++
libavfilter/x86/vf_maskedmerge_init.c | 2 ++
libavfilter/x86/vf_overlay_init.c | 2 ++
libavfilter/x86/vf_pp7_init.c | 2 ++
libavfilter/x86/vf_psnr_init.c | 2 ++
libavfilter/x86/vf_removegrain_init.c | 2 ++
libavfilter/x86/vf_ssim_init.c | 2 ++
libavfilter/x86/vf_stereo3d_init.c | 2 ++
libavfilter/x86/vf_threshold_init.c| 2 ++
libavfilter/x86/vf_tinterlace_init.c | 2 ++
libavfilter/x86/vf_transpose_init.c| 2 ++
libavfilter/x86/vf_v360_init.c | 2 ++
libavfilter/x86/vf_w3fdif_init.c | 2 ++
libavfilter/x86/vf_yadif_init.c| 2 ++
libavutil/x86/fixed_dsp_init.c | 2 ++
libavutil/x86/float_dsp_init.c | 2 ++
libavutil/x86/imgutils_init.c | 2 ++
libavutil/x86/lls_init.c | 2 ++
libavutil/x86/pixelutils_init.c| 2 ++
libswresample/x86/audio_convert_init.c | 2 ++
libswresample/x86/resample_init.c | 6 ++
libswscale/x86/rgb2rgb.c | 2 ++
libswscale/x86/swscale.c | 2 ++
81 files changed, 167 insertions(+), 5 deletions(-)
diff --git a/libavcodec/x86/aacencdsp_init.c
b/libavcodec/x86/aacencdsp_init.c
index 049a2417d9..7dca1d481b 100644
--- a/libavcodec/x86/aacencdsp_init.c
+++ b/libavcodec/x86/aacencdsp_init.c
@@ -34,6 +34,7 @@ void ff_aac_quantize_bands_sse2(int *out, const float
*in, const float *scaled,
av_cold void ff_aac_dsp_init_x86(AACEncContext *s)
{
+#if HAVE_X86ASM
int cpu_flags = av_get_cpu_flags();
if (EXTERNAL_SSE(cpu_flags))
@@ -41,4 +42,5 @@ av_cold void ff_aac_dsp_init_x86(AACEncContext *s)
if (EXTERNAL_SSE2(cpu_flags))
s->quant_bands = ff_aac_quantize_bands_sse2;
+#endif /* HAVE_X86ASM */
}
diff --git a/libavcodec/x86/aacpsdsp_init.c b/libavcodec/x86/aacpsdsp_init.c
index
[FFmpeg-devel] [PATCH v4 3/4] all: Guard if (INLINE*) checks with #if HAVE_INLINE_ASM
Continuation of 40e6575aa3eed64cd32bf28c00ae57edc5acb25a
Signed-off-by: L. E. Segovia
---
libavcodec/x86/hpeldsp_init.c | 2 ++
libavcodec/x86/vc1dsp_init.c | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
index 09c48c341e..6bde5a3893 100644
--- a/libavcodec/x86/hpeldsp_init.c
+++ b/libavcodec/x86/hpeldsp_init.c
@@ -224,8 +224,10 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c,
int flags)
{
int cpu_flags = av_get_cpu_flags();
+#if HAVE_INLINE_ASM
if (INLINE_MMX(cpu_flags))
hpeldsp_init_mmx(c, flags);
+#endif
if (EXTERNAL_MMXEXT(cpu_flags))
hpeldsp_init_mmxext(c, flags);
diff --git a/libavcodec/x86/vc1dsp_init.c b/libavcodec/x86/vc1dsp_init.c
index bc63933e83..65fc28ea35 100644
--- a/libavcodec/x86/vc1dsp_init.c
+++ b/libavcodec/x86/vc1dsp_init.c
@@ -102,7 +102,7 @@ av_cold void ff_vc1dsp_init_x86(VC1DSPContext *dsp)
{
int cpu_flags = av_get_cpu_flags();
-#if HAVE_6REGS
+#if HAVE_6REGS && HAVE_INLINE_ASM
if (INLINE_MMX(cpu_flags))
if (EXTERNAL_MMX(cpu_flags))
ff_vc1dsp_init_mmx(dsp);
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 2/4] all: Replace if (CONFIG_FOO) checks by #if CONFIG_FOO
Continuation of e42aaaf92a4b0c88d60acc12df64c81d0887c26f
Signed-off-by: L. E. Segovia
---
fftools/ffprobe.c | 16 +++-
fftools/opt_common.c| 12 ++--
libavformat/rtmpproto.c | 24 ++--
3 files changed, 39 insertions(+), 13 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a39185f6fe..c3e90a9409 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3572,9 +3572,9 @@ static void
ffprobe_show_program_version(WriterContext *w)
av_bprint_finalize(, NULL);
}
-#define SHOW_LIB_VERSION(libname, LIBNAME) \
-do {\
-if (CONFIG_##LIBNAME) { \
+#define SHOW_LIB_VERSION_0(libname, LIBNAME)
+#define SHOW_LIB_VERSION_1(libname, LIBNAME)\
+{ \
unsigned int version = libname##_version(); \
writer_print_section_header(w, SECTION_ID_LIBRARY_VERSION); \
print_str("name","lib" #libname); \
@@ -3584,8 +3584,14 @@ static void
ffprobe_show_program_version(WriterContext *w)
print_int("version", version); \
print_str("ident", LIB##LIBNAME##_IDENT); \
writer_print_section_footer(w); \
-} \
-} while (0)
+}
+
+#define SHOW_LIB_VERSION_2(cfg, libname, LIBNAME) \
+SHOW_LIB_VERSION_ ## cfg(libname, LIBNAME)
+#define SHOW_LIB_VERSION_3(cfg, libname, LIBNAME) \
+SHOW_LIB_VERSION_2(cfg, libname, LIBNAME)
+#define SHOW_LIB_VERSION(libname, LIBNAME) \
+SHOW_LIB_VERSION_3(CONFIG_ ## LIBNAME, libname, LIBNAME)
static void ffprobe_show_library_versions(WriterContext *w)
{
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 7c996f140d..5729d656e9 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -153,8 +153,9 @@ static int warned_cfg = 0;
#define SHOW_CONFIG 4
#define SHOW_COPYRIGHT 8
-#define PRINT_LIB_INFO(libname, LIBNAME, flags, level) \
-if (CONFIG_##LIBNAME) { \
+#define PRINT_LIB_INFO_0(libname, LIBNAME, flags, level)
+#define PRINT_LIB_INFO_1(libname, LIBNAME, flags, level)\
+{ \
const char *indent = flags & INDENT? " " : ""; \
if (flags & SHOW_VERSION) { \
unsigned int version = libname##_version(); \
@@ -182,6 +183,13 @@ static int warned_cfg = 0;
} \
} \
+#define PRINT_LIB_INFO_2(cfg, libname, LIBNAME, flags, level) \
+PRINT_LIB_INFO_ ## cfg(libname, LIBNAME, flags, level)
+#define PRINT_LIB_INFO_3(cfg, libname, LIBNAME, flags, level) \
+PRINT_LIB_INFO_2(cfg, libname, LIBNAME, flags, level)
+#define PRINT_LIB_INFO(libname, LIBNAME, flags, level) \
+PRINT_LIB_INFO_3(CONFIG_ ## LIBNAME, libname, LIBNAME, flags, level)
+
static void print_all_libs_info(int flags, int level)
{
PRINT_LIB_INFO(avutil, AVUTIL, flags, level);
diff --git a/libavformat/rtmpproto.c b/libavformat/rtmpproto.c
index f0ef223f05..6d84fcf34f 100644
--- a/libavformat/rtmpproto.c
+++ b/libavformat/rtmpproto.c
@@ -1222,7 +1222,8 @@ static int rtmp_handshake(URLContext *s,
RTMPContext *rt)
for (i = 9; i <= RTMP_HANDSHAKE_PACKET_SIZE; i++)
tosend[i] = av_lfg_get() >> 24;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* When the client wants to use RTMPE, we have to change the
command
* byte to 0x06 which means to use encrypted data and we have
to set
* the flash version to at least 9.0.115.0. */
@@ -1237,6 +1238,7 @@ static int rtmp_handshake(URLContext *s,
RTMPContext *rt)
if ((ret = ff_rtmpe_gen_pub_key(rt->stream, tosend + 1)) < 0)
return ret;
}
+#endif
client_pos = rtmp_handshake_imprint_with_digest(tosend + 1,
rt->encrypted);
if (client_pos < 0)
@@ -1300,7 +1302,8 @@ static int rtmp_handshake(URLContext *s,
RTMPContext *rt)
if (ret < 0)
return ret;
-if (CONFIG_FFRTMPCRYPT_PROTOCOL && rt->encrypted) {
+#if CONFIG_FFRTMPCRYPT_PROTOCOL
+if (rt->encrypted) {
/* Compute the shared secret key sent by the server and
initialize
* the RC4 encryption. */
if ((ret =
[FFmpeg-devel] [PATCH v4 1/4] all: Replace if (ARCH_FOO) checks by #if ARCH_FOO, part 2
Continuation of 40e6575aa3eed64cd32bf28c00ae57edc5acb25a
Co-authored-by: Nirbheek Chauhan
Signed-off-by: L. E. Segovia
---
libavcodec/x86/fdctdsp_init.c| 2 +
libavcodec/x86/flacdsp_init.c| 8 +-
libavcodec/x86/hevcdsp_init.c| 547 ++-
libavcodec/x86/idctdsp_init.c| 9 +-
libavcodec/x86/mlpdsp_init.c | 6 +-
libavcodec/x86/vc1dsp_init.c | 6 +-
libavfilter/x86/colorspacedsp_init.c | 4 +-
libavfilter/x86/vf_atadenoise_init.c | 6 +-
libavfilter/x86/vf_ssim_init.c | 4 +-
libavfilter/x86/vf_w3fdif_init.c | 4 +-
10 files changed, 311 insertions(+), 285 deletions(-)
diff --git a/libavcodec/x86/fdctdsp_init.c b/libavcodec/x86/fdctdsp_init.c
index 92a842433d..4a874a640d 100644
--- a/libavcodec/x86/fdctdsp_init.c
+++ b/libavcodec/x86/fdctdsp_init.c
@@ -31,8 +31,10 @@ av_cold void ff_fdctdsp_init_x86(FDCTDSPContext *c,
AVCodecContext *avctx,
if (!high_bit_depth) {
if ((dct_algo == FF_DCT_AUTO || dct_algo == FF_DCT_MMX)) {
+#if HAVE_INLINE_SSE2
if (INLINE_SSE2(cpu_flags))
c->fdct = ff_fdct_sse2;
+#endif
}
}
}
diff --git a/libavcodec/x86/flacdsp_init.c b/libavcodec/x86/flacdsp_init.c
index 87daed7005..49e67ee2b0 100644
--- a/libavcodec/x86/flacdsp_init.c
+++ b/libavcodec/x86/flacdsp_init.c
@@ -97,15 +97,19 @@ av_cold void ff_flacdsp_init_x86(FLACDSPContext *c,
enum AVSampleFormat fmt, int
}
if (EXTERNAL_AVX(cpu_flags)) {
if (fmt == AV_SAMPLE_FMT_S16) {
-if (ARCH_X86_64 && channels == 8)
+#if ARCH_X86_64
+if (channels == 8)
c->decorrelate[0] = ff_flac_decorrelate_indep8_16_avx;
+#endif
} else if (fmt == AV_SAMPLE_FMT_S32) {
if (channels == 4)
c->decorrelate[0] = ff_flac_decorrelate_indep4_32_avx;
else if (channels == 6)
c->decorrelate[0] = ff_flac_decorrelate_indep6_32_avx;
-else if (ARCH_X86_64 && channels == 8)
+#if ARCH_X86_64
+else if (channels == 8)
c->decorrelate[0] = ff_flac_decorrelate_indep8_32_avx;
+#endif
}
}
if (EXTERNAL_XOP(cpu_flags)) {
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index 6f45e5e0db..c7060085a2 100644
--- a/libavcodec/x86/hevcdsp_init.c
+++ b/libavcodec/x86/hevcdsp_init.c
@@ -710,13 +710,13 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const
int bit_depth)
if (EXTERNAL_SSE2(cpu_flags)) {
c->hevc_v_loop_filter_chroma =
ff_hevc_v_loop_filter_chroma_8_sse2;
c->hevc_h_loop_filter_chroma =
ff_hevc_h_loop_filter_chroma_8_sse2;
-if (ARCH_X86_64) {
-c->hevc_v_loop_filter_luma =
ff_hevc_v_loop_filter_luma_8_sse2;
-c->hevc_h_loop_filter_luma =
ff_hevc_h_loop_filter_luma_8_sse2;
+#if ARCH_X86_64
+c->hevc_v_loop_filter_luma = ff_hevc_v_loop_filter_luma_8_sse2;
+c->hevc_h_loop_filter_luma = ff_hevc_h_loop_filter_luma_8_sse2;
-c->idct[2] = ff_hevc_idct_16x16_8_sse2;
-c->idct[3] = ff_hevc_idct_32x32_8_sse2;
-}
+c->idct[2] = ff_hevc_idct_16x16_8_sse2;
+c->idct[3] = ff_hevc_idct_32x32_8_sse2;
+#endif
SAO_BAND_INIT(8, sse2);
c->idct_dc[1] = ff_hevc_idct_8x8_dc_8_sse2;
@@ -731,14 +731,14 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const
int bit_depth)
c->add_residual[3] = ff_hevc_add_residual_32_8_sse2;
}
if (EXTERNAL_SSSE3(cpu_flags)) {
-if(ARCH_X86_64) {
-c->hevc_v_loop_filter_luma =
ff_hevc_v_loop_filter_luma_8_ssse3;
-c->hevc_h_loop_filter_luma =
ff_hevc_h_loop_filter_luma_8_ssse3;
-}
+#if ARCH_X86_64
+c->hevc_v_loop_filter_luma =
ff_hevc_v_loop_filter_luma_8_ssse3;
+c->hevc_h_loop_filter_luma =
ff_hevc_h_loop_filter_luma_8_ssse3;
+#endif
SAO_EDGE_INIT(8, ssse3);
}
-if (EXTERNAL_SSE4(cpu_flags) && ARCH_X86_64) {
-
+#if ARCH_X86_64
+if (EXTERNAL_SSE4(cpu_flags)) {
EPEL_LINKS(c->put_hevc_epel, 0, 0, pel_pixels, 8, sse4);
EPEL_LINKS(c->put_hevc_epel, 0, 1, epel_h, 8, sse4);
EPEL_LINKS(c->put_hevc_epel, 1, 0, epel_v, 8, sse4);
@@ -749,16 +749,17 @@ void ff_hevc_dsp_init_x86(HEVCDSPContext *c, const
int bit_depth)
QPEL_LINKS(c->put_hevc_qpel, 1, 0, qpel_v, 8, sse4);
QPEL_LINKS(c->put_hevc_qpel, 1, 1, qpel_hv,8, sse4);
}
+#endif
if (EXTERNAL_AVX(cpu_flags)) {
c->hevc_v_loop_filter_chroma =
ff_hevc_v_loop_filter_chroma_8_avx;
c->hevc_h_loop_filter_chroma =
ff_hevc_h_loop_filter_chroma_8_avx;
-if (ARCH_X86_64) {
-c->hevc_v_loop_filter_luma =
ff_hevc_v_loop_filter_luma_8_avx;
-c->hevc_h_loop_filter_luma =
[FFmpeg-devel] [PATCH v4 0/4] Fix MSVC build without optimizations
Updated for 6.0, any constructive feedback will be appreciated. L. E. Segovia (4): all: Replace if (ARCH_FOO) checks by #if ARCH_FOO, part 2 all: Replace if (CONFIG_FOO) checks by #if CONFIG_FOO all: Guard if (INLINE*) checks with #if HAVE_INLINE_ASM all: Guard if (EXTERNAL*) checks with #if HAVE_X86ASM fftools/ffprobe.c | 16 +- fftools/opt_common.c | 12 +- libavcodec/x86/aacencdsp_init.c| 2 + libavcodec/x86/aacpsdsp_init.c | 2 + libavcodec/x86/ac3dsp_init.c | 4 + libavcodec/x86/audiodsp_init.c | 2 + libavcodec/x86/bswapdsp_init.c | 2 + libavcodec/x86/cavsdsp.c | 2 + libavcodec/x86/celt_pvq_init.c | 2 + libavcodec/x86/cfhddsp_init.c | 2 + libavcodec/x86/cfhdencdsp_init.c | 2 + libavcodec/x86/dcadsp_init.c | 2 + libavcodec/x86/dct_init.c | 2 + libavcodec/x86/dnxhdenc_init.c | 2 + libavcodec/x86/exrdsp_init.c | 2 + libavcodec/x86/fdctdsp_init.c | 2 + libavcodec/x86/fft_init.c | 2 + libavcodec/x86/flacdsp_init.c | 8 +- libavcodec/x86/g722dsp_init.c | 2 + libavcodec/x86/h263dsp_init.c | 2 + libavcodec/x86/h264_intrapred_init.c | 2 + libavcodec/x86/h264chroma_init.c | 2 + libavcodec/x86/hevcdsp_init.c | 549 +++-- libavcodec/x86/hpeldsp_init.c | 4 + libavcodec/x86/hpeldsp_vp3_init.c | 2 + libavcodec/x86/huffyuvdsp_init.c | 2 + libavcodec/x86/huffyuvencdsp_init.c| 2 + libavcodec/x86/idctdsp_init.c | 11 +- libavcodec/x86/jpeg2000dsp_init.c | 2 + libavcodec/x86/lossless_videodsp_init.c| 2 + libavcodec/x86/lossless_videoencdsp_init.c | 2 + libavcodec/x86/me_cmp_init.c | 2 + libavcodec/x86/mlpdsp_init.c | 6 +- libavcodec/x86/mpegvideoencdsp_init.c | 2 + libavcodec/x86/opusdsp_init.c | 2 + libavcodec/x86/pixblockdsp_init.c | 2 + libavcodec/x86/pngdsp_init.c | 2 + libavcodec/x86/proresdsp_init.c| 2 + libavcodec/x86/rv34dsp_init.c | 2 + libavcodec/x86/sbcdsp_init.c | 2 + libavcodec/x86/sbrdsp_init.c | 2 + libavcodec/x86/svq1enc_init.c | 2 + libavcodec/x86/utvideodsp_init.c | 2 + libavcodec/x86/v210enc_init.c | 6 +- libavcodec/x86/vc1dsp_init.c | 6 +- libavcodec/x86/vorbisdsp_init.c| 2 + libavcodec/x86/vp3dsp_init.c | 2 + libavcodec/x86/vp6dsp_init.c | 2 + libavfilter/x86/af_afir_init.c | 2 + libavfilter/x86/af_anlmdn_init.c | 2 + libavfilter/x86/af_volume_init.c | 2 + libavfilter/x86/avf_showcqt_init.c | 2 + libavfilter/x86/colorspacedsp_init.c | 6 +- libavfilter/x86/vf_atadenoise_init.c | 8 +- libavfilter/x86/vf_blend_init.c| 2 + libavfilter/x86/vf_bwdif_init.c| 2 + libavfilter/x86/vf_convolution_init.c | 2 +- libavfilter/x86/vf_framerate_init.c| 2 + libavfilter/x86/vf_fspp_init.c | 2 + libavfilter/x86/vf_gblur_init.c| 2 + libavfilter/x86/vf_hflip_init.c| 2 + libavfilter/x86/vf_limiter_init.c | 2 + libavfilter/x86/vf_maskedclamp_init.c | 2 + libavfilter/x86/vf_maskedmerge_init.c | 2 + libavfilter/x86/vf_overlay_init.c | 2 + libavfilter/x86/vf_pp7_init.c | 2 + libavfilter/x86/vf_psnr_init.c | 2 + libavfilter/x86/vf_removegrain_init.c | 2 + libavfilter/x86/vf_ssim_init.c | 6 +- libavfilter/x86/vf_stereo3d_init.c | 2 + libavfilter/x86/vf_threshold_init.c| 2 + libavfilter/x86/vf_tinterlace_init.c | 2 + libavfilter/x86/vf_transpose_init.c| 2 + libavfilter/x86/vf_v360_init.c | 2 + libavfilter/x86/vf_w3fdif_init.c | 6 +- libavfilter/x86/vf_yadif_init.c| 2 + libavformat/rtmpproto.c| 24 +- libavutil/x86/fixed_dsp_init.c | 2 + libavutil/x86/float_dsp_init.c | 2 + libavutil/x86/imgutils_init.c | 2 + libavutil/x86/lls_init.c | 2 + libavutil/x86/pixelutils_init.c| 2 + libswresample/x86/audio_convert_init.c | 2 + libswresample/x86/resample_init.c | 6 + libswscale/x86/rgb2rgb.c | 2 + libswscale/x86/swscale.c | 2 + 86 files changed, 517 insertions(+), 301 deletions(-) -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org
[FFmpeg-devel] [PATCH v2] vulkan_hevc: use diagonal scan order for scaling lists
The hevc parser parses the diagonal scan order in bitstream into raster
scan order. However, the Vulkan spec wants it as specified in H265 spec,
which is diagonal scan order.
Tested on RADV.
v2: fix copy-paste typo with PPS.
---
libavcodec/vulkan_hevc.c | 83
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
index ab0f6b96d0..1f157faf87 100644
--- a/libavcodec/vulkan_hevc.c
+++ b/libavcodec/vulkan_hevc.c
@@ -17,6 +17,7 @@
*/
#include "hevcdec.h"
+#include "hevc_data.h"
#include "hevc_ps.h"
#include "vulkan_decode.h"
@@ -205,6 +206,44 @@ static StdVideoH265LevelIdc convert_to_vk_level_idc(int
level_idc)
}
}
+static void copy_scaling_list(const ScalingList *sl,
+StdVideoH265ScalingLists *vksl)
+{
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS; j++)
{
+uint8_t pos = 4 * ff_hevc_diag_scan4x4_y[j] +
ff_hevc_diag_scan4x4_x[j];
+vksl->ScalingList4x4[i][j] = sl->sl[0][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_ELEMENTS; j++)
{
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList8x8[i][j] = sl->sl[1][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_ELEMENTS;
j++) {
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList16x16[i][j] = sl->sl[2][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_ELEMENTS;
j++) {
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList32x32[i][j] = sl->sl[3][i * 3][pos];
+}
+}
+
+memcpy(vksl->ScalingListDCCoef16x16, sl->sl_dc[0],
+STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS *
sizeof(*vksl->ScalingListDCCoef16x16));
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
+vksl->ScalingListDCCoef32x32[i] = sl->sl_dc[1][i * 3];
+}
+
static void set_sps(const HEVCSPS *sps, int sps_idx,
StdVideoH265ScalingLists *vksps_scaling,
StdVideoH265HrdParameters *vksps_vui_header,
@@ -218,27 +257,7 @@ static void set_sps(const HEVCSPS *sps, int sps_idx,
StdVideoH265ShortTermRefPicSet *str,
StdVideoH265LongTermRefPicsSps *ltr)
{
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList4x4[i], sps->scaling_list.sl[0][i],
- STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList4x4));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList8x8[i], sps->scaling_list.sl[1][i],
- STD_VIDEO_H265_SCALING_LIST_8X8_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList8x8));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList16x16[i], sps->scaling_list.sl[2][i],
- STD_VIDEO_H265_SCALING_LIST_16X16_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList16x16));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList32x32[i], sps->scaling_list.sl[3][i *
3],
- STD_VIDEO_H265_SCALING_LIST_32X32_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList32x32));
-
-memcpy(vksps_scaling->ScalingListDCCoef16x16, sps->scaling_list.sl_dc[0],
- STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS *
sizeof(*vksps_scaling->ScalingListDCCoef16x16));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
-vksps_scaling->ScalingListDCCoef32x32[i] =
sps->scaling_list.sl_dc[1][i * 3];
+copy_scaling_list(>scaling_list, vksps_scaling);
*vksps_vui_header = (StdVideoH265HrdParameters) {
.flags = (StdVideoH265HrdFlags) {
@@ -464,27 +483,7 @@ static void set_pps(const HEVCPPS *pps, const HEVCSPS *sps,
StdVideoH265PictureParameterSet *vkpps,
StdVideoH265PredictorPaletteEntries *pal)
{
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++)
-memcpy(vkpps_scaling->ScalingList4x4[i], pps->scaling_list.sl[0][i],
- STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS *
sizeof(**vkpps_scaling->ScalingList4x4));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++)
-memcpy(vkpps_scaling->ScalingList8x8[i],
[FFmpeg-devel] [PATCH 2/2] Move sdr within the libavradio repository
This moves sdr back from libavradio into libavdevice & libavformat
(inside the libavradio repository)
People originally wanted this code in a libavradio library but recently
suggested that sdr should have no impact on other things in FFmpeg.
libavradio has a substantial impact as it will result in distributions
packaging a new library.
Also there is currently no API specific to sdr, its just the input
device API. So until a new API is created there is no benefit from
a new library in the release.
This also avoids the need for build system changes for a new library
---
Makefile | 5 +-
configure | 36 +-
fftools/ffmpeg.c | 5 -
fftools/ffplay.c | 4 -
fftools/ffprobe.c | 4 -
fftools/opt_common.c | 62 +
fftools/opt_common.h | 27
libavdevice/Makefile | 1 +
libavdevice/alldevices.c | 1 +
.../sdrinradio.c => libavdevice/sdrindev.c| 18 +--
libavdevice/utils.c | 2 +-
libavformat/Makefile | 1 +
libavformat/allformats.c | 33 ++---
libavformat/internal.h| 1 -
{libavradio => libavformat}/rds.c | 0
{libavradio => libavformat}/sdr.h | 20 +--
.../sdr_vissualize.c | 0
{libavradio => libavformat}/sdrdemux.c| 28 ++--
libavradio/Makefile | 15 ---
libavradio/allradios.c| 66 --
libavradio/avradio.c | 32 -
libavradio/avradio.h | 121 --
libavradio/internal.h | 28
libavradio/utils.c| 59 -
libavradio/version.c | 45 ---
libavradio/version.h | 45 ---
libavradio/version_major.h| 36 --
libavutil/log.h | 1 -
tools/uncoded_frame.c | 4 -
29 files changed, 55 insertions(+), 645 deletions(-)
rename libavradio/sdrinradio.c => libavdevice/sdrindev.c (98%)
rename {libavradio => libavformat}/rds.c (100%)
rename {libavradio => libavformat}/sdr.h (95%)
rename libavradio/vissualize.c => libavformat/sdr_vissualize.c (100%)
rename {libavradio => libavformat}/sdrdemux.c (99%)
delete mode 100644 libavradio/Makefile
delete mode 100644 libavradio/allradios.c
delete mode 100644 libavradio/avradio.c
delete mode 100644 libavradio/avradio.h
delete mode 100644 libavradio/internal.h
delete mode 100644 libavradio/utils.c
delete mode 100644 libavradio/version.c
delete mode 100644 libavradio/version.h
delete mode 100644 libavradio/version_major.h
diff --git a/Makefile b/Makefile
index d5689231c3..bf1b69f96b 100644
--- a/Makefile
+++ b/Makefile
@@ -19,14 +19,13 @@ vpath %/fate_config.sh.template $(SRC_PATH)
TESTTOOLS = audiogen videogen rotozoom tiny_psnr tiny_ssim base64 audiomatch
HOSTPROGS := $(TESTTOOLS:%=tests/%) doc/print_options
-ALLFFLIBS = avcodec avdevice avfilter avformat avradio avutil postproc swscale
swresample
+ALLFFLIBS = avcodec avdevice avfilter avformat avutil postproc swscale
swresample
# $(FFLIBS-yes) needs to be in linking order
FFLIBS-$(CONFIG_AVDEVICE) += avdevice
FFLIBS-$(CONFIG_AVFILTER) += avfilter
FFLIBS-$(CONFIG_AVFORMAT) += avformat
FFLIBS-$(CONFIG_AVCODEC)+= avcodec
-FFLIBS-$(CONFIG_AVRADIO)+= avradio
FFLIBS-$(CONFIG_POSTPROC) += postproc
FFLIBS-$(CONFIG_SWRESAMPLE) += swresample
FFLIBS-$(CONFIG_SWSCALE)+= swscale
@@ -172,7 +171,7 @@ distclean:: clean
libavcodec/bsf_list.c libavformat/protocol_list.c \
libavcodec/codec_list.c libavcodec/parser_list.c \
libavfilter/filter_list.c libavdevice/indev_list.c
libavdevice/outdev_list.c \
- libavformat/muxer_list.c libavformat/demuxer_list.c
libavradio/inradio_list.c
+ libavformat/muxer_list.c libavformat/demuxer_list.c
ifeq ($(SRC_LINK),src)
$(RM) src
endif
diff --git a/configure b/configure
index b104455822..23c9df3b73 100755
--- a/configure
+++ b/configure
@@ -75,7 +75,6 @@ Help options:
--list-indevsshow all available input devices
--list-outdevs show all available output devices
--list-filters show all available filters
- --list-inradios show all available input radios
Standard options:
--logfile=FILE log tests and output to FILE [ffbuild/config.log]
@@ -129,7 +128,6 @@ Component options:
--disable-avdevice disable libavdevice build
--disable-avcodecdisable libavcodec build
--disable-avformat disable libavformat build
- --disable-avradio
[FFmpeg-devel] [PATCH 1/2] avradio/sdr: Add CQUAM support
untested as i have no clean signal from a CQUAM station
Signed-off-by: Michael Niedermayer
---
libavradio/sdr.h | 1 +
libavradio/sdrdemux.c | 37 +++--
2 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/libavradio/sdr.h b/libavradio/sdr.h
index 6d11ef794f..b27e6a719e 100644
--- a/libavradio/sdr.h
+++ b/libavradio/sdr.h
@@ -50,6 +50,7 @@ typedef enum AMMode {
AMLeftRight,
AMInPhase,
AMEnvelope,
+AMCQUAM,
AMModeNB,
} AMMode;
diff --git a/libavradio/sdrdemux.c b/libavradio/sdrdemux.c
index 3b24cfedef..78c933f6f1 100644
--- a/libavradio/sdrdemux.c
+++ b/libavradio/sdrdemux.c
@@ -805,13 +805,35 @@ static int demodulate_am(SDRContext *sdr, Station
*station, AVStream *st, AVPack
wamp = amp/stamp;
mm = (AVComplexFloat){dc1.re * amp, -dc1.im * amp};
-for(i = 0; i<2*sdr->am_block_size; i++) {
-AVComplexFloat v = sdr->am_iblock[i];
-sdr->am_iblock[i].re = v.re*mm.re - v.im*mm.im - sdr->am_window[i]
* wamp;
-sdr->am_iblock[i].im = v.re*mm.im + v.im*mm.re;
-}
+if (am_mode == AMCQUAM) {
+double vdotw = 0;
+for(i = 0; i<2*sdr->am_block_size; i++) {
+AVComplexFloat v = sdr->am_iblock[i];
+float I = v.re*mm.re - v.im*mm.im;
+float Q = v.re*mm.im + v.im*mm.re;
+float m = sqrt(I*I + Q*Q);
+//An ideal signal needs no limit but a real noisy signal can
become 0 and negative, The limit of 2.0 is arbitrary and still needs to be
tuned once we have real world test signals
+float s = Q * FFMIN(m / fabs(I), 2.0);
+
+sdr->am_iblock[i].re = m;
+sdr->am_iblock[i].im = s;
+vdotw += sdr->am_window[i] * m;
+}
+vdotw /= dcw ;
+for (i = 0; i<2*sdr->am_block_size; i++) {
+float w = sdr->am_window[i];
+sdr->am_iblock[i].re -= w*vdotw;
+}
-scale = 0.9;
+scale = 0.9/vdotw;
+} else {
+for(i = 0; i<2*sdr->am_block_size; i++) {
+AVComplexFloat v = sdr->am_iblock[i];
+sdr->am_iblock[i].re = v.re*mm.re - v.im*mm.im -
sdr->am_window[i] * wamp;
+sdr->am_iblock[i].im = v.re*mm.im + v.im*mm.re;
+}
+scale = 0.9;
+}
}
for(i = 0; i<2*sdr->am_block_size; i++) {
@@ -832,10 +854,12 @@ static int demodulate_am(SDRContext *sdr, Station
*station, AVStream *st, AVPack
switch(am_mode) {
case AMMidSide:
case AMLeftRight:
+case AMCQUAM:
q = sst->out_buf[2*i+1] + sdr->am_iblock[i
].im * sdr->am_window[i ] * scale;
newbuf[2*i+1] = sdr->am_iblock[i +
sdr->am_block_size].im * sdr->am_window[i + sdr->am_block_size] * scale;
switch(am_mode) {
case AMMidSide:
+case AMCQUAM:
q *= 0.5;
sst->out_buf[2*i+0] = m + q;
sst->out_buf[2*i+1] = m - q;
@@ -2316,6 +2340,7 @@ const AVOption ff_sdr_options[] = {
{ "am_midside", "AM Demodulation Mid Side", 0, AV_OPT_TYPE_CONST,
{.i64 = AMMidSide}, 0, 0, DEC, "am_mode"},
{ "am_inphase", "AM Demodulation In Phase", 0, AV_OPT_TYPE_CONST,
{.i64 = AMInPhase}, 0, 0, DEC, "am_mode"},
{ "am_envelope","AM Demodulation EnvelopeDC", 0, AV_OPT_TYPE_CONST,
{.i64 = AMEnvelope}, 0, 0, DEC, "am_mode"},
+{ "am_cquam","CQUAM Stereo Demodulation", 0, AV_OPT_TYPE_CONST, {.i64
= AMCQUAM}, 0, 0, DEC, "am_mode"},
{ "am_fft_ref", "Use FFT Based carrier for AM demodulation",
OFFSET(am_fft_ref), AV_OPT_TYPE_INT , {.i64 = 0}, 0, 1, DEC},
--
2.31.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/6] avradio/sdrinradio: Check tuner before applying rtlsdr frequency correction
On Mon, Jul 24, 2023 at 08:35:30PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavradio/sdrinradio.c | 15 +-- > 1 file changed, 9 insertions(+), 6 deletions(-) will apply patchset to libavradio repository [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. 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] [RFC] tools/patcheck: portability fixes.
On Thu, Jul 27, 2023 at 08:15:52PM +0200, reimar.doeffin...@gmx.de wrote:
> From: Reimar Döffinger
>
> Enough to make it run on macOS.
> In particular:
> - fix "empty subexpression" errors caused by constructs like (smth|),
> use ? instead to make them optional
> - no -d option for xargs, use the more standard -0 and use tr to
> replace newlines with 0.
>
> Not sure if these cause issues somewhere else, not even completely
> sure they all work, but quick testing suggests they work.
> On the other hand I remember issues with '?' where I resorted to {0,1}
> instead, but I do not remember details.
> Ignore if fixing these seems not worth the risk.
> ---
> tools/patcheck | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
making it work on more platforms is a good idea.
It seems still working here on ubuntu but i certainly dont know which
syntax constructs work where
[...]
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
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] [FFmpeg-cvslog] fftools/cmdutils: add error handling to GROW_ARRAY()
On Thu, Jul 20, 2023 at 06:57:15PM +, Anton Khirnov wrote: > ffmpeg | branch: master | Anton Khirnov | Fri Jul 14 > 12:28:18 2023 +0200| [2e6afa799ef693b94f993f54ed41a84f6d9f1685] | committer: > Anton Khirnov > > fftools/cmdutils: add error handling to GROW_ARRAY() > > > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=2e6afa799ef693b94f993f54ed41a84f6d9f1685 > --- > > fftools/cmdutils.c| 44 ++-- > fftools/cmdutils.h| 6 +- > fftools/ffmpeg_demux.c| 10 -- > fftools/ffmpeg_mux_init.c | 15 --- > fftools/ffmpeg_opt.c | 24 +++- > fftools/ffplay.c | 5 - > 6 files changed, 78 insertions(+), 26 deletions(-) this feels wrong: Reading option '-nostats' ... matched as option 'stats' (print progress report during encoding) with argument 0. Reading option '-y' ... matched as option 'y' (overwrite output files) with argument '1'. Reading option '-report' ... matched as option 'report' (generate a report) with argument '1'. -Reading option '-i' ... matched as input url with argument 'videos/mm-short.mpg'. +Reading option '-i' ... matched as output url with argument 'videos/mm-short.mpg'. Reading option '-bitexact' ... matched as option 'bitexact' (bitexact mode) with argument '1'. Reading option '-t' ... matched as option 't' (record or transcode "duration" seconds of audio/video) with argument '1'. Reading option 'doom_tmp/report/file.avi' ... matched as output url. FFREPORT=file=/tmp/report ./ffmpeg -v repeat+verbose -nostats -y -report -i ~/videos/mm-short.mpg -bitexact -t 1 /tmp/file.avi [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The bravest are surely those who have the clearest vision of what is before them, glory and danger alike, and yet notwithstanding go out to meet it. -- Thucydides 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 v2 0/3] avcodec: move HDR10 (MDCV/CLL) SEI handling to h2645_sei
On Thu, Jul 27, 2023 at 12:37 AM Jan Ekström wrote: > > On Tue, Jul 25, 2023 at 10:29 PM Jan Ekström wrote: > > > > This allows parsing code to be re-utilized from H.264, as well as probably > > from VVC in the future. > > > > This additionally eases verification of the AVCodecContext side data patch > > set, which includes libx264 integration for HDR10 side data. > > > > Changes from v1: > > * Reordered the new h2645_sei include to correct location as per > > alphabetical > > order. Thanks for Leo Izen for noticing this. > > * Cleaned up the mastering_display_metadata.h include in hevcdec, as that > > file > > no longer directly handles AVContentLightMetadata or > > AVMasteringDisplayMetadata. > > > > Notes: > > * In addition to testing with FATE, looking at the show_frames ffprobe > > output > > for a UHD BD sample with each IRAP containing these SEI entries, the > > behavior is the same as before with regards to each frame having the side > > data persist. > > > > There is also no change with tests I've done with a UHD BD mp4 remux as > > well > > as an iphone 12 sample I had around, So I think I have not modified the > > HEVC > > behavior in any great manner. > > * As for H.264, it now automatically gains support for these SEI messages. > > It > > seems like its definition of CVS (coded video sequence) is from one IDR to > > another (essentially a GOP). That said, currently the decoder resets the > > SEI > > setup in decode_nal_units, which means that the side data only persist for > > a single frame. > > > > Unless there are objections, I will apply this tomorrow evening as > this is a strict improvement over the current situation where the > parsing is limited to HEVC and at least checking with ffprobe does not > show regressions for HEVC. > Applied the set as 33358b862c8b796362218f12555e351aaf35a8f4 , 43e63ff20a51e0296c446a9deec613df6fd52cb8 and 91e1d11d1405f325f6f52e2c8dd5bbbf2462e190. Jan ___ 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/v4l2_context: suppress POLLERR when buffers are uninitialized
On Tue, 25 Jul 2023, Richard Acayan wrote:
A POLLERR occurs when libavcodec attempts to dequeue output buffers
before enqueuing capture buffers. This could happen to an application
deciding to send the first coded packet. Suppress these POLLERRs when
the buffers are uninitialized.
Will apply, thanks.
Marton
See https://trac.ffmpeg.org/ticket/9957 for the original bug report.
Signed-off-by: Richard Acayan
---
Changes since v1 (20230718220017.3336-1-mailingrad...@gmail.com):
- stopped emitting POLLERR logs for this case (thanks to feedback from
Marton Balint)
libavcodec/v4l2_context.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
index a40be94690..f20f713e1d 100644
--- a/libavcodec/v4l2_context.c
+++ b/libavcodec/v4l2_context.c
@@ -325,9 +325,13 @@ start:
/* 0. handle errors */
if (pfd.revents & POLLERR) {
-/* if we are trying to get free buffers but none have been queued yet
- no need to raise a warning */
+/* if we are trying to get free buffers but none have been queued yet,
+ * or if no buffers have been allocated yet, no need to raise a warning
+ */
if (timeout == 0) {
+if (!ctx->buffers)
+return NULL;
+
for (i = 0; i < ctx->num_buffers; i++) {
if (ctx->buffers[i].status != V4L2BUF_AVAILABLE)
av_log(logger(ctx), AV_LOG_WARNING, "%s POLLERR\n",
ctx->name);
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: fix misleading indentation warnings after ticks_per_frame deprecation
On Sat, 22 Jul 2023, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/libaomenc.c | 3 ++-
libavcodec/libvpxenc.c | 3 ++-
libavcodec/msmpeg4enc.c | 3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
Will apply.
Regards,
Marton
diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index 16747e7e92..f29cb0784a 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -1299,7 +1299,7 @@ static int aom_encode(AVCodecContext *avctx, AVPacket
*pkt,
duration = frame->duration;
else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
duration = av_rescale_q(1, av_inv_q(avctx->framerate),
avctx->time_base);
-else
+else {
FF_DISABLE_DEPRECATION_WARNINGS
duration =
#if FF_API_TICKS_PER_FRAME
@@ -1307,6 +1307,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
#endif
1;
FF_ENABLE_DEPRECATION_WARNINGS
+}
switch (frame->color_range) {
case AVCOL_RANGE_MPEG:
diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 549ac55aaa..7a545527a9 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1830,7 +1830,7 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket
*pkt,
duration = frame->duration;
else if (avctx->framerate.num > 0 && avctx->framerate.den > 0)
duration = av_rescale_q(1, av_inv_q(avctx->framerate),
avctx->time_base);
-else
+else {
FF_DISABLE_DEPRECATION_WARNINGS
duration =
#if FF_API_TICKS_PER_FRAME
@@ -1838,6 +1838,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
#endif
1;
FF_ENABLE_DEPRECATION_WARNINGS
+}
res = vpx_codec_encode(>encoder, rawimg, timestamp,
duration, flags, ctx->deadline);
diff --git a/libavcodec/msmpeg4enc.c b/libavcodec/msmpeg4enc.c
index 9828901bea..a8ddb8d8e1 100644
--- a/libavcodec/msmpeg4enc.c
+++ b/libavcodec/msmpeg4enc.c
@@ -284,7 +284,7 @@ void ff_msmpeg4_encode_ext_header(MpegEncContext * s)
if (s->avctx->framerate.num > 0 && s->avctx->framerate.den > 0)
fps = s->avctx->framerate.num / s->avctx->framerate.den;
-else
+else {
FF_DISABLE_DEPRECATION_WARNINGS
fps = s->avctx->time_base.den / s->avctx->time_base.num
#if FF_API_TICKS_PER_FRAME
@@ -292,6 +292,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
#endif
;
FF_ENABLE_DEPRECATION_WARNINGS
+}
put_bits(>pb, 5, FFMIN(fps, 31)); //yes 29.97 -> 29
--
2.35.3
___
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] fftools/ffprobe: fix handling parse_options() return value
On Wed, 26 Jul 2023, Anton Khirnov wrote:
---
fftools/ffprobe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a39185f6fe..81610c097b 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -4113,7 +4113,7 @@ int main(int argc, char **argv)
show_banner(argc, argv, options);
ret = parse_options(NULL, argc, argv, options, opt_input_file);
if (ret < 0) {
-ret = AVERROR_EXIT ? 0 : ret;
+ret = (ret == AVERROR_EXIT) ? 0 : ret;
goto end;
LGTM, thanks.
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/Makefile: Unconditionally skip vulkan_video_codec_av1std.h
Jul 24, 2023, 22:46 by andreas.rheinha...@outlook.com: > libavcodec/vulkan_video_codec_av1std.h currently does not pass > checkheaders: It is missing stdint.h and vulkan/vulkan_core.h. > The comment "This header is NOT YET generated from the Khronos Vulkan > XML API Registry." as well as the fact that it does not use our standard > inclusion guards makes the file appear as if it is to be treated > like a third-party header and not one of our own. This commit > therefore "fixes" the issue by unconditionally skipping said header. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/Makefile | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > LGTM Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/flvdec: use avio operation instead of pb->buf_ptr use
On Thu, 27 Jul 2023, Steven Liu wrote:
check ensure seekback 4 bytes before read 4 bytes from pb,
and seek back 4 byte from current position after read 4 bytes.
fix segfaults:
READ of size 1 at 0x610003b7 thread T0
#0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
#1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
#2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
#3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
#4 0x71d158 in avformat_find_stream_info ffmpeg/libavformat/demux.c:2634:15
#5 0x4c821b in LLVMFuzzerTestOneInput ffmpeg/tools/target_dem_fuzzer.c:206:11
Signed-off-by: Steven Liu
---
libavformat/flvdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 3fe21622f7..38f34567dd 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -35,6 +35,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/mathematics.h"
#include "avformat.h"
+#include "avio_internal.h"
#include "demux.h"
#include "internal.h"
#include "flv.h"
@@ -313,8 +314,14 @@ static int flv_same_video_codec(AVFormatContext *s,
AVCodecParameters *vpar, int
return 1;
if (flv->exheader) {
-uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
-uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 | codec_id_str[1]
<< 16 | codec_id_str[0] << 24;
+uint32_t codec_id = 0;
+int ret = ffio_ensure_seekback(s->pb, 4);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "Could not ensure seekback, because %s",
av_err2str(ret));
+return 0;
+}
+codec_id = avio_rb32(s->pb);
+avio_seek(s->pb, -4, SEEK_CUR);
Can't you rework the code to not do any IO here? It is super confusing
that a function called "flv_same_video_codec" actually reads stuff instead
of using only its parameters to check it.
IMHO the fourcc should be read where VideoTagHeader is read, not here. And
the fourcc should be passed as parameter to flv_same_video_codec. Or maybe
you can use a new variable called videocodecid, and set it to either
fourcc or legacy videocodecid, and pass only that to flv_same_video_codec.
Regards,
Marton
___
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] os_support, network: Fix build failure on Windows with BZIP2
Including winsock2.h without WIN32_LEAN_AND_MEAN causes bzlib.h to parse as nonsense, due to an instance of #define char small in rpcndr.h (included transitively from windows.h). See: https://stackoverflow.com/a/27794577 Signed-off-by: L. E. Segovia --- libavformat/network.h| 1 + libavformat/os_support.c | 6 ++ libavformat/os_support.h | 1 + 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/libavformat/network.h b/libavformat/network.h index ca214087fc..06b6117fc7 100644 --- a/libavformat/network.h +++ b/libavformat/network.h @@ -35,6 +35,7 @@ #endif #if HAVE_WINSOCK2_H +#define WIN32_LEAN_AND_MEAN #include #include diff --git a/libavformat/os_support.c b/libavformat/os_support.c index 15cea7fa5b..2de6a7c3d9 100644 --- a/libavformat/os_support.c +++ b/libavformat/os_support.c @@ -34,11 +34,9 @@ #if HAVE_SYS_TIME_H #include #endif /* HAVE_SYS_TIME_H */ -#if HAVE_WINSOCK2_H -#include -#elif HAVE_SYS_SELECT_H +#if HAVE_SYS_SELECT_H #include -#endif /* HAVE_WINSOCK2_H */ +#endif /* HAVE_SYS_SELECT_H */ #endif /* !HAVE_POLL_H */ #include "network.h" diff --git a/libavformat/os_support.h b/libavformat/os_support.h index f2ff38e23b..5bdd275d70 100644 --- a/libavformat/os_support.h +++ b/libavformat/os_support.h @@ -140,6 +140,7 @@ typedef int socklen_t; typedef unsigned long nfds_t; #if HAVE_WINSOCK2_H +#define WIN32_LEAN_AND_MEAN #include #endif #if !HAVE_STRUCT_POLLFD -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Michael Niedermayer (12023-07-27): > Now gqrx needs me to manually enter the frequency, the modulation the > device, then it still doesnt work (first one has to know why from multiple > rtlsdr lines some dont work) and once one is through this it still > doesnt work, all AGC methods dont work, i have to set the gain manually > for the station i want to listen to to have acceptable quality. I do know > but at this point we lost likely 90% of users already who dont realize that > the AGC sets a too high gain Also, can gqrx (or other tools based on the same backends) record from a V4L device at the same time, process the video to add text or overlay a logo or decrease the noise, process the audio to normalize the volume or mix it with background music, encode it into a variety of codecs and save the result into a file while at the same time publishing it as a Youtube Live stream? Because if something is integrated, then ffmpeg can do all that. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
On Thu, Jul 27, 2023 at 03:05:23PM +0200, Tomas Härdin wrote: > ons 2023-07-26 klockan 12:37 +0200 skrev Michael Niedermayer: > > > But what my goal after > > having some fun with SDR is, is to > > serve the end user. And here iam > > trying to make it possible that "FFmpeg based" players and tools > > can use SDR. > > Which tools and players? Thats a good question. I did not state that clearly probably The idea really is any tool which is able to use an arbitrary demuxer / input device. all of our tools (ffplay, ffprobe, ffmpeg) work but our doc/examples should work too Also id like to say thanks for writing this mail without terse attacks like some other replies i got. > > > For FFmpeg using a C or C++ libraray for some parts of SDR like DAB > > is something that makes sense and i plan to go that route. But beyond > > that I simply do not understand how your suggestions would server > > end users > > End users are already served by existing programs like gqrx. I disagree, let me explain Let me first explain what i want to provide to the user (most of this is already implemented, some needs more work) the user starts her favorite player, be that vlc, ffplay, or whatever chooses sdr as input device and thats all configuration she needs. She can select a specific driver, gain and so but she doesnt have to Now she only needs 2 buttons, seek forward and seek backward, in ffplay thats the cursor keys. To select the station. And she sees on the screen what station that is, what song title and artist are playing as well as what is playing on any other FM station in view (that works here already in europe, for the US if it doesnt work i need a sample from dumpurl ...) (for non interactive tools like ffmpeg she would have to select the frequency she wants to listen to or all in view ...) Now gqrx needs me to manually enter the frequency, the modulation the device, then it still doesnt work (first one has to know why from multiple rtlsdr lines some dont work) and once one is through this it still doesnt work, all AGC methods dont work, i have to set the gain manually for the station i want to listen to to have acceptable quality. I do know but at this point we lost likely 90% of users already who dont realize that the AGC sets a too high gain Also gqrx doesnt tell me what iam listening to, the name of the radio station? the artist ? the song name ? nothing like this is shown and if i want to switch to the next station i have to enter its frequency or click on the location of the radio spectrum gqrx is a tool a radio amateur like you will be happy with (and i realize likely more powerfull tools would fit even better) but i think the average user wants to listen to or record broadcast radio and have as little to mess with and has the maximum information like song names and titles available > My point > is rather about the sanity of our developers, and of downstream > developers. The fact that you don't mention downstream projects by name > tells me that you haven't asked them The original plan of an input device should not affect anyone in any way who doesnt want to use it. Its just another device. libavradio could affect people because it could be an extra dependancy an extra package and so on. I will propose a patchset to libavradio that avoids this. Thanks! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] [RFC] tools/patcheck: portability fixes.
From: Reimar Döffinger
Enough to make it run on macOS.
In particular:
- fix "empty subexpression" errors caused by constructs like (smth|),
use ? instead to make them optional
- no -d option for xargs, use the more standard -0 and use tr to
replace newlines with 0.
Not sure if these cause issues somewhere else, not even completely
sure they all work, but quick testing suggests they work.
On the other hand I remember issues with '?' where I resorted to {0,1}
instead, but I do not remember details.
Ignore if fixing these seems not worth the risk.
---
tools/patcheck | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/tools/patcheck b/tools/patcheck
index fe52938f29..ee993c60fc 100755
--- a/tools/patcheck
+++ b/tools/patcheck
@@ -21,7 +21,7 @@ echo may or may not be bad. When you use it and it misses
something or detects
echo something wrong, fix it and send a patch to the ffmpeg-devel mailing list.
echo License: GPL, Author: Michael Niedermayer
-ERE_PRITYP='(unsigned *|)(char|short|long|int|long *int|short
*int|void|float|double|(u|)int(8|16|32|64)_t)'
+ERE_PRITYP='(unsigned *)?(char|short|long|int|long *int|short
*int|void|float|double|u?int(8|16|32|64)_t)'
ERE_TYPES='(const|static|av_cold|inline|
*)*('$ERE_PRITYP'|[a-zA-Z][a-zA-Z0-9_]*)[* ]{1,}[a-zA-Z][a-zA-Z0-9_]*'
ERE_FUNCS="$ERE_TYPES"' *\('
@@ -63,7 +63,7 @@ hiegrep '\+= *1 *;' 'can be simplified to ++' $*
hiegrep '-= *1 *;' 'can be simplified to --' $*
hiegrep '((!|=)= *(0|NULL)[^0-9a-z]|[^0-9a-z](0|NULL) *(!|=)=)' 'x==0 / x!=0
can be simplified to !x / x' $*
-$EGREP $OPT '^\+ *(const *|)static' $*| $EGREP --color=always '[^=]=
*(0|NULL)[^0-9a-zA-Z]'> $TMP && printf '\nuseless 0 init\n'
+$EGREP $OPT '^\+ *(const *)?static' $*| $EGREP --color=always '[^=]=
*(0|NULL)[^0-9a-zA-Z]'> $TMP && printf '\nuseless 0 init\n'
cat $TMP
hiegrep '# *ifdef * (HAVE|CONFIG)_' 'ifdefs that should be #if' $*
@@ -77,7 +77,7 @@ hiegrep ':\+ *'"$ERE_PRITYP"' *inline' 'non static inline or
strangely ordered i
hiegrep "$ERE_FUNCS"' *\)' 'missing void' $*
hiegrep '(sprintf|strcat|strcpy)' 'Possible security issue, make sure this is
safe or use snprintf/av_strl*' $*
hiegrep '/
*(2|4|8|16|32|64|128|256|512|1024|2048|4096|8192|16384|32768|65536)[^0-9]'
'divide by 2^x could use >> maybe' $*
-hiegrep '#(el|)if *(0|1)' 'useless #if' $*
+hiegrep '#(el)?if *(0|1)' 'useless #if' $*
hiegrep 'if *\( *(0|1) *\)' 'useless if()' $*
hiegrep '& *[a-zA-Z0-9_]* *\[ *0 *\]' 'useless & [0]' $*
hiegrep '(\( *[0-9] *(&&|\|\|)|(&&|\|\|) *[0-9] *\))' 'overriding condition' $*
@@ -118,22 +118,22 @@ if test -e $TMP ; then
cat $TMP
fi
-$EGREP -B2 $OPT '^(\+|) *('"$ERE_TYPES"'|# *define)' $* | $EGREP -A2
--color=always '(:|-)\+[^/]*/(\*([^*]|$)|/([^/]|$))' > $TMP && printf "\n Non
doxy comments\n"
+$EGREP -B2 $OPT '^\+? *('"$ERE_TYPES"'|# *define)' $* | $EGREP -A2
--color=always '(:|-)\+[^/]*/(\*([^*]|$)|/([^/]|$))' > $TMP && printf "\n Non
doxy comments\n"
cat $TMP
rm $TMP
for i in \
$($EGREP -H '^\+ *'"$ERE_TYPES" $* |\
$GREP -v '(' | $EGREP -v '\Wgoto\W' |\
-xargs -d '\n' -n 1 |\
+tr '\n' '\0' | xargs -0 -n 1 |\
$GREP -o '[* ][* ]*[a-zA-Z][0-9a-zA-Z_]* *[,;=]' |\
sed 's/.[* ]*\([a-zA-Z][0-9a-zA-Z_]*\) *[,;=]/\1/') \
; do
echo $i | $GREP '^NULL$' && continue
-$EGREP $i' *(\+|-|\*|/|\||&|%|)=[^=]' $* >/dev/null || echo "possibly
never written:"$i >> $TMP
+$EGREP $i' *(\+|-|\*|/|\||&|%)?=[^=]' $* >/dev/null || echo "possibly
never written:"$i >> $TMP
$EGREP '(=|\(|return).*'$i'(==|[^=])*$'$* >/dev/null || echo "possibly
never read :"$i >> $TMP
-$EGREP -o $i' *((\+|-|\*|/|\||&|%|)=[^=]|\+\+|--) *(0x|)[0-9]*(;|)' $* |\
- $EGREP -v $i' *= *(0x|)[0-9]{1,};'>/dev/null || echo "possibly
constant :"$i >> $TMP
+$EGREP -o $i' *((\+|-|\*|/|\||&|%)?=[^=]|\+\+|--) *(0x)?[0-9]*;?' $* |\
+ $EGREP -v $i' *= *(0x)?[0-9]{1,};'>/dev/null || echo "possibly
constant :"$i >> $TMP
done
if test -e $TMP ; then
printf '\npossibly unused variables\n'
@@ -151,7 +151,7 @@ cat $TMP | tr '@' '\n'
cat $* | tr '\n' '@' | $EGREP --color=always -o '\+ *if *\( *([A-Za-z0-9_]*)
*[<>]=? *([A-Za-z0-9_]*) *\)[ @\\+]*(\1|\2) *= *(\1|\2) *;' >$TMP && printf
"\nFFMIN/FFMAX\n"
cat $TMP | tr '@' '\n'
-cat $* | tr '\n' '@' | $EGREP --color=always -o '\+ *if *\( *([A-Za-z0-9_]*)
*\)[ @\\+]*av_free(p|) *\( *(&|) *\1[^-.]' >$TMP && printf "\nav_free(NULL) is
safe\n"
+cat $* | tr '\n' '@' | $EGREP --color=always -o '\+ *if *\( *([A-Za-z0-9_]*)
*\)[ @\\+]*av_freep? *\( *&? *\1[^-.]' >$TMP && printf "\nav_free(NULL) is
safe\n"
cat $TMP | tr '@' '\n'
cat $* | tr '\n' '@' | $EGREP --color=always -o '[^a-zA-Z0-9_]([a-zA-Z0-9_]*)
*= *av_malloc *\([^)]*\)[ @;\\+]*memset *\( *\1' >$TMP && printf
"\nav_mallocz()\n"
--
2.37.1 (Apple Git-137.1)
___
ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH 5/6] fftools: avradio support
Kieran Kunhya (12023-07-25): > You can have satisified users without having to implement SDR in a > multimedia library, nor xml parsing, nor a web server, nor anything > else that sits at a higher or lower level than FFmpeg. Satisfied users is not a yes/no thing. There was a branch of the fork with more features and more satisfied users, and a branch of the fork with less features and less satisfied users. The second one died, and good riddance. We are on the branch of the fork that wants more features even if it means a few hacks. Accept it or work on the other branch. > It's not just multimedia that goes over radio, it's not just > multimedia that goes over TCP, it's not just multimedia that needs > XML, that's why there are separate libraries for these kind of things. It is not just multimedia that can be encrypted, yet FFmpeg has cryptographic primitives. It is not just multimedia that can go over HTTP, yet FFmpeg has support for HTTP — limited to its needs. It is not just multimedia that requires Fourier transforms and similar mathematical operations, yet FFmpeg has them too. > FFmpeg is not the kitchen sink of miscellaneous wheel reinvention. I reject the disparaging “kitchen sink”, but apart from it, YES, FFmpeg is exactly that, or at least it was some time before the fork. Then some people pushed for more seriousness, more stability, which meant less creativity. And seeing their efforts to make the project more serious, more stable and more sterile were not succeeding enough, they tried to take over, that resulted in a fork that almost killed the project. And we, on the FFmpeg side, made the mistake to try to entice them back. We changed for that, we made the project more serious, more stable, more sterile, to try and convince them to come back. We should not have done so. Instead, we should have reaffirmed what makes FFmpeg not libav, and demanded THEY change to be welcomed back. And so the trend towards more seriousness, more stability, more sterility, continued. Amplified by people who started business to exploit FFmpeg, and have a personal interest in the project being more serious, more stable, and don't care it's more sterile. But before that evolution, what FFmpeg success in the first place, was precisely that it was a welcoming place for development in the multimedia field. Not just a narrow version of “the scope”, but anything related to multimedia, or useful for it. Not just things that do not exist elsewhere but also projects to invent new and creative ways of doing it. And since that ambiance attracted very talented hackers (including you personally, as far as I could see), it frequently gave impressive results. So yes, being able to use SDR devices to record AM/FM on the fly from ffmpeg or any FFmpeg-based application is worth a few hacks here and there. And yes, being able to read network streams defined by XML manifests without linking to the big stinking pile of shite that is libxml2 is worth having our own XML parser, limited to exactly what we need instead of supporting the whole complex format. And so on and so on. FFmpeg is a place for creativity. If you do not agree, try to remember why you came here in the first place. -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libaformat: fix incorrect handling of incomplete AVBPrint.
Reimar Döffinger (12023-07-27): > Thanks, sent a new version with that updated, plus a fix for a typo > in the commit message. If it is all you have changed, then I do not think I need to look at it again. I do not maintain most of the files you have changed, but I think you can go ahead. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 0/7] webp: add support for animated WebP decoding
On Thu, Jul 27, 2023 at 4:29 AM Thilo Borgmann wrote: > > Am 25.07.23 um 22:14 schrieb James Zern: > > On Tue, Jul 25, 2023 at 1:58 AM Thilo Borgmann > > wrote: > >> > >> Still images fixed from v2. Now includes a fate test for animated webp. > >> > >> Patch 5/7 is still there for making changes in lavc/webp reviewable but > >> shall be stashed when pushing. > >> > >> -Thilo > >> > >> > >> Josef Zlomek (2): > >>libavcodec/webp: add support for animated WebP decoding > >>libavformat/webp: add WebP demuxer > >> > >> Thilo Borgmann (5): > >>avcodec/webp: move definitions into header > >>avcodec/webp: remove unused definitions > >>avcodec/webp_parser: parse each frame into one packet > >>avcodec/webp: make init_canvas_frame static > >>fate: add test for animated WebP > >> > >> Changelog | 2 + > >> doc/demuxers.texi | 28 + > >> libavcodec/codec_desc.c | 3 +- > >> libavcodec/version.h| 2 +- > >> libavcodec/webp.c | 715 +-- > >> libavcodec/webp.h | 38 + > >> libavcodec/webp_parser.c| 130 ++-- > >> libavformat/Makefile| 1 + > >> libavformat/allformats.c| 1 + > >> libavformat/version.h | 2 +- > >> libavformat/webpdec.c | 733 > >> tests/fate/image.mak| 3 + > >> tests/ref/fate/exif-image-webp | 12 +- > >> tests/ref/fate/webp-anim| 22 + > >> tests/ref/fate/webp-rgb-lena-lossless | 2 +- > >> tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- > >> tests/ref/fate/webp-rgb-lossless| 2 +- > >> tests/ref/fate/webp-rgb-lossy-q80 | 2 +- > >> tests/ref/fate/webp-rgba-lossless | 2 +- > >> tests/ref/fate/webp-rgba-lossy-q80 | 2 +- > >> 20 files changed, 1589 insertions(+), 115 deletions(-) > >> create mode 100644 libavcodec/webp.h > >> create mode 100644 libavformat/webpdec.c > >> create mode 100644 tests/ref/fate/webp-anim > >> > > > > This series is lgtm. There are still a few edge cases where > > > 1) the > > 'Canvas change detected' warning will be triggered with valid files, > > As long as the canvas in frame threading is bound to a ThreadFrame, we can't > reallocate for changes. > Wouldn't want to touch that until the new threading is all done. > > > > 2) corrupt / truncated files will produce output where they would fail > > with libwebp and > > We might bail out as well though AFAICT we usually try to decode whatever > might be possible. > > > > 3) I see quite a few "[webp @ 0x7f5530008c00] > > Multiple ff_thread_finish_setup() calls", not sure if that's expected. > > Which sample you're looking at? > > If I can reproduce this, I'll look at it. The other things I'd keep as they > are. > I see this with: https://www.gstatic.com/webp/gallery3/1_webp_a.webp Using an animation it seems to be output once per frame. ___ 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] libaformat: fix incorrect handling of incomplete AVBPrint.
> On 27 Jul 2023, at 19:33, Nicolas George wrote: > > reimar.doeffin...@gmx.de (12023-07-23): >> From: Reimar Döffinger >> >> Change some internal APIs a bit to make it harder to make >> such mistakes. >> In particular, have the read chunk functions return an error >> when the result is incomplete. >> This might be less flexible, but since there has been no >> use-case for that so far, avoiding coding mistakes seems better. >> Add a function to queue a AVBPrint directly >> (ff_subtitles_queue_insert_bprint). >> Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails. >> --- >> libavformat/assdec.c | 4 +++- >> libavformat/lrcdec.c | 7 ++- >> libavformat/mpsubdec.c | 5 +++-- >> libavformat/realtextdec.c| 6 +- >> libavformat/samidec.c| 6 +- >> libavformat/srtdec.c | 4 +++- >> libavformat/subtitles.c | 17 + >> libavformat/subtitles.h | 14 -- >> libavformat/tedcaptionsdec.c | 2 +- >> libavformat/webvttdec.c | 4 +++- >> 10 files changed, 54 insertions(+), 15 deletions(-) > > Sorry I forgot I meant to review. These changes look for the best, > except > >> +if (!av_bprint_is_complete(event)) return NULL; > >> +if (i == INT_MAX) return AVERROR_INVALIDDATA; > > … which do not follow the coding style. Thanks, sent a new version with that updated, plus a fix for a typo in the commit message. ___ 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] libavformat: fix incorrect handling of incomplete AVBPrint.
From: Reimar Döffinger
Change some internal APIs a bit to make it harder to make
such mistakes.
In particular, have the read chunk functions return an error
when the result is incomplete.
This might be less flexible, but since there has been no
use-case for that so far, avoiding coding mistakes seems better.
Add a function to queue a AVBPrint directly (ff_subtitles_queue_insert_bprint).
Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails.
Signed-off-by: Reimar Döffinger
---
libavformat/assdec.c | 4 +++-
libavformat/lrcdec.c | 7 ++-
libavformat/mpsubdec.c | 5 +++--
libavformat/realtextdec.c| 6 +-
libavformat/samidec.c| 6 +-
libavformat/srtdec.c | 4 +++-
libavformat/subtitles.c | 19 +++
libavformat/subtitles.h | 14 --
libavformat/tedcaptionsdec.c | 2 +-
libavformat/webvttdec.c | 4 +++-
10 files changed, 56 insertions(+), 15 deletions(-)
diff --git a/libavformat/assdec.c b/libavformat/assdec.c
index 0915f6fafd..bf7b8a73a2 100644
--- a/libavformat/assdec.c
+++ b/libavformat/assdec.c
@@ -73,6 +73,8 @@ static int read_dialogue(ASSContext *ass, AVBPrint *dst,
const uint8_t *p,
av_bprint_clear(dst);
av_bprintf(dst, "%u,%d,%s", ass->readorder++, layer, p + pos);
+if (!av_bprint_is_complete(dst))
+return AVERROR(ENOMEM);
/* right strip the buffer */
while (dst->len > 0 &&
@@ -135,7 +137,7 @@ static int ass_read_header(AVFormatContext *s)
av_bprintf(, "%s", line.str);
continue;
}
-sub = ff_subtitles_queue_insert(>q, rline.str, rline.len, 0);
+sub = ff_subtitles_queue_insert_bprint(>q, , 0);
if (!sub) {
res = AVERROR(ENOMEM);
goto end;
diff --git a/libavformat/lrcdec.c b/libavformat/lrcdec.c
index fff39495f8..83bb4a4b75 100644
--- a/libavformat/lrcdec.c
+++ b/libavformat/lrcdec.c
@@ -171,6 +171,8 @@ static int lrc_read_header(AVFormatContext *s)
while(!avio_feof(s->pb)) {
int64_t pos = read_line(, s->pb);
+if (!av_bprint_is_complete())
+goto err_nomem_out;
int64_t header_offset = find_header(line.str);
if(header_offset >= 0) {
char *comma_offset = strchr(line.str, ':');
@@ -205,7 +207,7 @@ static int lrc_read_header(AVFormatContext *s)
sub = ff_subtitles_queue_insert(>q, line.str +
ts_strlength,
line.len - ts_strlength, 0);
if (!sub)
-return AVERROR(ENOMEM);
+goto err_nomem_out;
sub->pos = pos;
sub->pts = ts_start - lrc->ts_offset;
sub->duration = -1;
@@ -216,6 +218,9 @@ static int lrc_read_header(AVFormatContext *s)
ff_metadata_conv_ctx(s, NULL, ff_lrc_metadata_conv);
av_bprint_finalize(, NULL);
return 0;
+err_nomem_out:
+av_bprint_finalize(, NULL);
+return AVERROR(ENOMEM);
}
const AVInputFormat ff_lrc_demuxer = {
diff --git a/libavformat/mpsubdec.c b/libavformat/mpsubdec.c
index d290a41fb9..0374563575 100644
--- a/libavformat/mpsubdec.c
+++ b/libavformat/mpsubdec.c
@@ -116,9 +116,10 @@ static int mpsub_read_header(AVFormatContext *s)
AVPacket *sub;
const int64_t pos = avio_tell(s->pb);
-ff_subtitles_read_chunk(s->pb, );
+res = ff_subtitles_read_chunk(s->pb, );
+if (res < 0) goto end;
if (buf.len) {
-sub = ff_subtitles_queue_insert(>q, buf.str, buf.len,
0);
+sub = ff_subtitles_queue_insert_bprint(>q, , 0);
if (!sub) {
res = AVERROR(ENOMEM);
goto end;
diff --git a/libavformat/realtextdec.c b/libavformat/realtextdec.c
index c281dec346..7992a5b7fc 100644
--- a/libavformat/realtextdec.c
+++ b/libavformat/realtextdec.c
@@ -80,6 +80,10 @@ static int realtext_read_header(AVFormatContext *s)
const int64_t pos = ff_text_pos() - (c != 0);
int n = ff_smil_extract_next_text_chunk(, , );
+if (n < 0) {
+res = n;
+goto end;
+}
if (n == 0)
break;
@@ -103,7 +107,7 @@ static int realtext_read_header(AVFormatContext *s)
/* if we just read a tag, introduce a new event, otherwise
merge
* with the previous one */
int merge = !av_strncasecmp(buf.str, "q, buf.str, buf.len, merge);
+sub = ff_subtitles_queue_insert_bprint(>q, , merge);
if (!sub) {
res = AVERROR(ENOMEM);
goto end;
diff --git a/libavformat/samidec.c b/libavformat/samidec.c
index 0da299343d..070b623ebf 100644
--- a/libavformat/samidec.c
+++ b/libavformat/samidec.c
@@ -68,6 +68,10 @@ static int sami_read_header(AVFormatContext *s)
const int64_t pos = ff_text_pos() - (c != 0);
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/evc_ps: Check num_ref_pic_list_in_sps
On Wed, Jul 26, 2023 at 09:19:10PM -0300, James Almer wrote:
> On 7/26/2023 8:59 PM, Michael Niedermayer wrote:
> > Fixes: out of array write
> > Fixes:
> > 60798/clusterfuzz-testcase-minimized-ffmpeg_BSF_EVC_FRAME_MERGE_fuzzer-4633529766772736
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/evc_ps.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/libavcodec/evc_ps.c b/libavcodec/evc_ps.c
> > index 04ee6a45e6..64384a392c 100644
> > --- a/libavcodec/evc_ps.c
> > +++ b/libavcodec/evc_ps.c
> > @@ -243,11 +243,20 @@ int ff_evc_parse_sps(GetBitContext *gb, EVCParamSets
> > *ps)
> > sps->rpl1_same_as_rpl0_flag = get_bits1(gb);
> > sps->num_ref_pic_list_in_sps[0] = get_ue_golomb(gb);
> > +if ((unsigned)sps->num_ref_pic_list_in_sps[0] >= EVC_MAX_NUM_RPLS)
> > {
>
> EVC_MAX_NUM_RPLS should be 64, not 32 as it's currently defined. So change
> that too and it LGTM.
ok will do
thx for reviewing
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2
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] libaformat: fix incorrect handling of incomplete AVBPrint.
reimar.doeffin...@gmx.de (12023-07-23): > From: Reimar Döffinger > > Change some internal APIs a bit to make it harder to make > such mistakes. > In particular, have the read chunk functions return an error > when the result is incomplete. > This might be less flexible, but since there has been no > use-case for that so far, avoiding coding mistakes seems better. > Add a function to queue a AVBPrint directly > (ff_subtitles_queue_insert_bprint). > Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails. > --- > libavformat/assdec.c | 4 +++- > libavformat/lrcdec.c | 7 ++- > libavformat/mpsubdec.c | 5 +++-- > libavformat/realtextdec.c| 6 +- > libavformat/samidec.c| 6 +- > libavformat/srtdec.c | 4 +++- > libavformat/subtitles.c | 17 + > libavformat/subtitles.h | 14 -- > libavformat/tedcaptionsdec.c | 2 +- > libavformat/webvttdec.c | 4 +++- > 10 files changed, 54 insertions(+), 15 deletions(-) Sorry I forgot I meant to review. These changes look for the best, except > +if (!av_bprint_is_complete(event)) return NULL; > +if (i == INT_MAX) return AVERROR_INVALIDDATA; … which do not follow the coding style. (The dynamic buffer writer of the AVWriter API makes it much harder to forget checking. But AVWriter is currently in limbo waiting for this project to reaffirm its orientation.) Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libaformat: fix incorrect handling of incomplete AVBPrint.
> On 23 Jul 2023, at 14:00, reimar.doeffin...@gmx.de wrote: > > From: Reimar Döffinger > > Change some internal APIs a bit to make it harder to make > such mistakes. > In particular, have the read chunk functions return an error > when the result is incomplete. > This might be less flexible, but since there has been no > use-case for that so far, avoiding coding mistakes seems better. > Add a function to queue a AVBPrint directly > (ff_subtitles_queue_insert_bprint). > Also fixes a leak in lrcdec when ff_subtitles_queue_insert fails. Please make any objections or need for more time to review known soon. Otherwise I plan on pushing in a few days. Best regards, Reimar ___ 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] hevcdsp_idct_neon.S: Avoid unnecessary mov.
> On 26 Jul 2023, at 21:43, Martin Storsjö wrote: > > On Wed, 26 Jul 2023, reimar.doeffin...@gmx.de wrote: > >> From: Reimar Döffinger >> >> ret can be given an argument instead. >> This is also consistent with how other assembler code >> in FFmpeg does it. >> --- >> libavcodec/aarch64/hevcdsp_idct_neon.S | 6 ++ >> 1 file changed, 2 insertions(+), 4 deletions(-) >> >> diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S >> b/libavcodec/aarch64/hevcdsp_idct_neon.S >> index b7f23386a4..f7142c939c 100644 >> --- a/libavcodec/aarch64/hevcdsp_idct_neon.S >> +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S >> @@ -617,8 +617,7 @@ function ff_hevc_idct_16x16_\bitdepth\()_neon, export=1 >> >>add sp, sp, #640 >> -mov x30, x15 >> -ret >> +ret x15 >> endfunc >> .endm >> @@ -814,8 +813,7 @@ function ff_hevc_idct_32x32_\bitdepth\()_neon, export=1 >> .endr >> >>add sp, sp, #2432 >> -mov x30, x15 >> -ret >> +ret x15 >> endfunc >> .endm > > LGTM, assuming checkasm still passes. It does. Will push soon (on the assumption I still can...) if no objections. Best regards, Reimar ___ 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] Replace br return with ret
> On 27 Jul 2023, at 15:55, Rémi Denis-Courmont wrote: > > Hi, > > The use of RET vs BR also has microarchitectural side effects. AFAIU, RET > should always be paired with an earlier BL/BLR to avoid interfering with > branch prediction. > > So depending on the circumstances, either one of these should be addressed: > * Clarify that this is actually a function return , and RET should be used > anyway, regardless of BTI. > * Keep BR and add BTI J landing pads where appropriate, if this wasn't really > a function return. Yes BL and RET is best to match up. For this function: % git grep func_tr_32x4 libavcodec/aarch64/hevcdsp_idct_neon.S:function func_tr_32x4_\name libavcodec/aarch64/hevcdsp_idct_neon.S:bl func_tr_32x4_firstpass libavcodec/aarch64/hevcdsp_idct_neon.S:bl func_tr_32x4_secondpass_\bitdepth libavcodec/arm/hevcdsp_idct_neon.S:function func_tr_32x4_\name libavcodec/arm/hevcdsp_idct_neon.S:bl func_tr_32x4_firstpass libavcodec/arm/hevcdsp_idct_neon.S:bl func_tr_32x4_secondpass_\bitdepth It is always used with "bl", thus ret is also more correct from that aspect. Was your comment only on checking that, or did you mean that this should be mentioned in the commit message? (if you are wondering why the code did not use ret before, I guess it's because it was ported from the 32-bit arm assembler and it slipped by code review) Best regards, Reimar ___ 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 3/7] avcodec/webp_parser: parse each frame into one packet
On Wed, Jul 26, 2023 at 2:36 PM Tomas Härdin wrote: > > tis 2023-07-25 klockan 16:18 +0200 skrev Thilo Borgmann: > > Am 25.07.23 um 14:24 schrieb Tomas Härdin: > > > > +// Extremely simplified key frame detection: > > > > +// - the first frame (containing headers) is marked as a key > > > > frame > > > > +// - other frames are marked as non-key frames > > > > > > Is there a more proper way of doing this? > > > > All frames (except the ANMF chunks) are INTRA, and all of them have a > > WEBP tag. > > Whereas all ANMF chunks are in the same WEBP chunk as their reference > > frame. > > So it should really be as simple as it is to mark all WEBP frames as > > key frames as the code does. > > What more dedicated do you have in mind? > > Nah mostly just curious. It just feels so weird when VP8 intra already > exists. Maybe I'm missing something. Browsers already support VP8 after > all. > We wanted something lighter weight (memory, cpu) for an image format rather than going full blown video. Lossless also factored into this. > > The logic as-is works with all samples I have, animated and not. > > Seems to also align well with their example file layouts. > > You have a more weird one? > > Nope ___ 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] vulkan_hevc: use diagonal scan order for scaling lists
The hevc parser parses the diagonal scan order in bitstream into raster
scan order. However, the Vulkan spec wants it as specified in H265 spec,
which is diagonal scan order.
Tested on RADV.
---
libavcodec/vulkan_hevc.c | 83
1 file changed, 41 insertions(+), 42 deletions(-)
diff --git a/libavcodec/vulkan_hevc.c b/libavcodec/vulkan_hevc.c
index ab0f6b96d0..15f2c3aa82 100644
--- a/libavcodec/vulkan_hevc.c
+++ b/libavcodec/vulkan_hevc.c
@@ -17,6 +17,7 @@
*/
#include "hevcdec.h"
+#include "hevc_data.h"
#include "hevc_ps.h"
#include "vulkan_decode.h"
@@ -205,6 +206,44 @@ static StdVideoH265LevelIdc convert_to_vk_level_idc(int
level_idc)
}
}
+static void copy_scaling_list(const ScalingList *sl,
+ StdVideoH265ScalingLists *vksl)
+{
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS; j++)
{
+uint8_t pos = 4 * ff_hevc_diag_scan4x4_y[j] +
ff_hevc_diag_scan4x4_x[j];
+vksl->ScalingList4x4[i][j] = sl->sl[0][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_ELEMENTS; j++)
{
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList8x8[i][j] = sl->sl[1][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_ELEMENTS;
j++) {
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList16x16[i][j] = sl->sl[2][i][pos];
+}
+}
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++) {
+for (int j = 0; j < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_ELEMENTS;
j++) {
+uint8_t pos = 8 * ff_hevc_diag_scan8x8_y[j] +
ff_hevc_diag_scan8x8_x[j];
+vksl->ScalingList32x32[i][j] = sl->sl[3][i * 3][pos];
+}
+}
+
+memcpy(vksl->ScalingListDCCoef16x16, sl->sl_dc[0],
+STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS *
sizeof(*vksl->ScalingListDCCoef16x16));
+
+for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
+vksl->ScalingListDCCoef32x32[i] = sl->sl_dc[1][i * 3];
+}
+
static void set_sps(const HEVCSPS *sps, int sps_idx,
StdVideoH265ScalingLists *vksps_scaling,
StdVideoH265HrdParameters *vksps_vui_header,
@@ -218,27 +257,7 @@ static void set_sps(const HEVCSPS *sps, int sps_idx,
StdVideoH265ShortTermRefPicSet *str,
StdVideoH265LongTermRefPicsSps *ltr)
{
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList4x4[i], sps->scaling_list.sl[0][i],
- STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList4x4));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList8x8[i], sps->scaling_list.sl[1][i],
- STD_VIDEO_H265_SCALING_LIST_8X8_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList8x8));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList16x16[i], sps->scaling_list.sl[2][i],
- STD_VIDEO_H265_SCALING_LIST_16X16_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList16x16));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
-memcpy(vksps_scaling->ScalingList32x32[i], sps->scaling_list.sl[3][i *
3],
- STD_VIDEO_H265_SCALING_LIST_32X32_NUM_ELEMENTS *
sizeof(**vksps_scaling->ScalingList32x32));
-
-memcpy(vksps_scaling->ScalingListDCCoef16x16, sps->scaling_list.sl_dc[0],
- STD_VIDEO_H265_SCALING_LIST_16X16_NUM_LISTS *
sizeof(*vksps_scaling->ScalingListDCCoef16x16));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_32X32_NUM_LISTS; i++)
-vksps_scaling->ScalingListDCCoef32x32[i] =
sps->scaling_list.sl_dc[1][i * 3];
+copy_scaling_list(>scaling_list, vksps_scaling);
*vksps_vui_header = (StdVideoH265HrdParameters) {
.flags = (StdVideoH265HrdFlags) {
@@ -464,27 +483,7 @@ static void set_pps(const HEVCPPS *pps, const HEVCSPS *sps,
StdVideoH265PictureParameterSet *vkpps,
StdVideoH265PredictorPaletteEntries *pal)
{
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_4X4_NUM_LISTS; i++)
-memcpy(vkpps_scaling->ScalingList4x4[i], pps->scaling_list.sl[0][i],
- STD_VIDEO_H265_SCALING_LIST_4X4_NUM_ELEMENTS *
sizeof(**vkpps_scaling->ScalingList4x4));
-
-for (int i = 0; i < STD_VIDEO_H265_SCALING_LIST_8X8_NUM_LISTS; i++)
-memcpy(vkpps_scaling->ScalingList8x8[i], pps->scaling_list.sl[1][i],
-
Re: [FFmpeg-devel] [PATCH v3 4/4] bsf: Add new bitstream filter to set SCTE-35 pts_adjustment when reclocking
On 7/21/2023 5:37 PM, Devin Heitmueller wrote:
Because SCTE-35 messages are represented in TS streams as sections
rather than PES packets, we cannot rely on ffmpeg's standard
mechanisms to adjust PTS values if reclocking the stream.
This filter will leverage the SCTE-35 pts_adjust field to
compensate for any change in the PTS values in the stream.
See SCTE-35 2019 Sec 9.6 for information about the use of
the pts_adjust field.
This filter also tweaks the mpegtsenc mux to automatically
add it so the user doesn't have to include it manually.
Thanks to Andreas Rheinhardt for providing feedback/suggestions
on improving the patch.
Signed-off-by: Devin Heitmueller
---
doc/bitstream_filters.texi | 9
libavcodec/Makefile | 1 +
libavcodec/bitstream_filters.c | 1 +
libavcodec/scte35ptsadjust_bsf.c | 103 +++
libavformat/mpegtsenc.c | 2 +
5 files changed, 116 insertions(+)
create mode 100644 libavcodec/scte35ptsadjust_bsf.c
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index c63c203..068b0c9 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -797,6 +797,15 @@ Remove extradata from all frames.
@end table
@end table
+@section scte35ptsadjust
+This bitstream filter makes use of side data injected by the MPEG-TS demux
+in order to rewrite the PTS adjust field within SCTE-35 packets. This
+ensures the pts_adjust field contains a valid value if the caller changes
+the timebase of the stream.
+
+The bitstream filter is added automatically by the mpegtsenc mux, and no
+action is required on the part of the user.
+
@section setts
Set PTS and DTS in packets.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 1b0226c..4c1b312 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1253,6 +1253,7 @@ OBJS-$(CONFIG_PCM_RECHUNK_BSF)+=
pcm_rechunk_bsf.o
OBJS-$(CONFIG_PGS_FRAME_MERGE_BSF)+= pgs_frame_merge_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
OBJS-$(CONFIG_REMOVE_EXTRADATA_BSF) += remove_extradata_bsf.o
av1_parse.o
+OBJS-$(CONFIG_SCTE35PTSADJUST_BSF)+= scte35ptsadjust_bsf.o
OBJS-$(CONFIG_SETTS_BSF) += setts_bsf.o
OBJS-$(CONFIG_TEXT2MOVSUB_BSF)+= movsub_bsf.o
OBJS-$(CONFIG_TRACE_HEADERS_BSF) += trace_headers_bsf.o
diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
index 1e9a676..60ed164 100644
--- a/libavcodec/bitstream_filters.c
+++ b/libavcodec/bitstream_filters.c
@@ -57,6 +57,7 @@ extern const FFBitStreamFilter ff_pcm_rechunk_bsf;
extern const FFBitStreamFilter ff_pgs_frame_merge_bsf;
extern const FFBitStreamFilter ff_prores_metadata_bsf;
extern const FFBitStreamFilter ff_remove_extradata_bsf;
+extern const FFBitStreamFilter ff_scte35ptsadjust_bsf;
extern const FFBitStreamFilter ff_setts_bsf;
extern const FFBitStreamFilter ff_text2movsub_bsf;
extern const FFBitStreamFilter ff_trace_headers_bsf;
diff --git a/libavcodec/scte35ptsadjust_bsf.c b/libavcodec/scte35ptsadjust_bsf.c
new file mode 100644
index 000..9870737
--- /dev/null
+++ b/libavcodec/scte35ptsadjust_bsf.c
@@ -0,0 +1,103 @@
+/*
+ * SCTE-35 PTS fixup bitstream filter
+ * Copyright (c) 2023 LTN Global Communications, Inc.
+ *
+ * Author: Devin Heitmueller
+ *
+ * Because SCTE-35 messages are represented in TS streams as sections
+ * rather than PES packets, we cannot rely on ffmpeg's standard
+ * mechanisms to adjust PTS values if reclocking the stream.
+ * This filter will leverage the SCTE-35 pts_adjust field to
+ * compensate for any change in the PTS values in the stream.
+ *
+ * See SCTE-35 2019 Sec 9.6 for information about the use of
+ * the pts_adjust field.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "bsf.h"
+#include "bsf_internal.h"
+#include "defs.h"
+#include "libavutil/intreadwrite.h"
+
+static int scte35ptsadjust_filter(AVBSFContext *ctx, AVPacket *pkt)
+{
+const AVTransportTimestamp *transport_ts;
+int64_t cur_pts_adjust;
+int ret = 0;
+
+ret = ff_bsf_get_packet_ref(ctx, pkt);
+if (ret < 0)
+return ret;
+
+/* Retrieve the original PTS, which will be used
Re: [FFmpeg-devel] [PATCH v3 0/4] Add passthrough support for SCTE-35
On Fri, Jul 21, 2023 at 4:38 PM Devin Heitmueller wrote: > > Properly set up the MPEG-TS mux and recalculate the pts_adjust field > in SCTE_35 packets, such that a user can transparently pass through > SCTE-35 streams when both the input and output are MPEG-TS. > > This patch series rebased against master and a patch to hack around > periodic PCR retransmission has been dropped as the behavior is > no longer reproducible in master. > > Devin Heitmueller (4): > avcodec: Add new side data type to contain original PTS value > mpegts: Stash original PTS for SCTE-35 sections for processing later > mpegtsenc: Add support for output of SCTE-35 streams over TS > bsf: Add new bitstream filter to set SCTE-35 pts_adjustment when > reclocking > > doc/bitstream_filters.texi | 9 > libavcodec/Makefile | 1 + > libavcodec/bitstream_filters.c | 1 + > libavcodec/defs.h| 12 + > libavcodec/packet.h | 11 + > libavcodec/scte35ptsadjust_bsf.c | 103 > +++ > libavformat/mpegts.c | 11 - > libavformat/mpegts.h | 1 + > libavformat/mpegtsenc.c | 76 +++-- > libavformat/mux.c| 6 ++- > 10 files changed, 224 insertions(+), 7 deletions(-) > create mode 100644 libavcodec/scte35ptsadjust_bsf.c > > -- > 1.8.3.1 > Given all the comments/feedback has been addressed and there haven't been any further comments, is there any reason this can't be merged by someone? Thank you, Devin -- Devin Heitmueller, Senior Software Engineer LTN Global Communications o: +1 (301) 363-1001 w: https://ltnglobal.com e: devin.heitmuel...@ltnglobal.com ___ 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] Replace br return with ret
Hi, The use of RET vs BR also has microarchitectural side effects. AFAIU, RET should always be paired with an earlier BL/BLR to avoid interfering with branch prediction. So depending on the circumstances, either one of these should be addressed: * Clarify that this is actually a function return , and RET should be used anyway, regardless of BTI. * Keep BR and add BTI J landing pads where appropriate, if this wasn't really a function return. Br, ___ 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 v26 5/9] avcodec/evc_decoder: Provided support for EVC decoder
> -Original Message-
> From: ffmpeg-devel On Behalf Of James
> Almer
> Sent: środa, 26 lipca 2023 17:46
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v26 5/9] avcodec/evc_decoder: Provided
> support for EVC decoder
>
> On 6/15/2023 8:48 AM, Dawid Kozinski wrote:
> > - Added EVC decoder wrapper
> > - Changes in project configuration file and libavcodec Makefile
> > - Added documentation for xevd wrapper
> >
> > Signed-off-by: Dawid Kozinski
>
> I'm getting
>
> [evc @ 01ee1ba7e960] An invalid frame was output by a decoder. This is
a
> bug, please report it.
> [vist#0:0/evc @ 01ee1d47f220] Decoding error: Internal bug, should not
> have happened
>
> With akiyo_cif.evc, so there's something wrong.
We have just started investigating the cause of this issue. The error
message always appears when the decoder receives the last data packet to be
decoded, just before transitioning to the draining state (when no new data
is coming but there are still some data that reside inside decoder and must
be processed).
After receiving the last data packet, during the data decoding process, the
frame_validate function (decode.c) is called, and it receives a pointer to
an AVFrame object. Inside this function, there is a check for the condition
frame->buf[0] != NULL, which is not met.
>
> > ---
> > configure | 4 +
> > doc/decoders.texi | 24 ++
> > doc/general_contents.texi | 10 +-
> > libavcodec/Makefile | 1 +
> > libavcodec/allcodecs.c| 1 +
> > libavcodec/libxevd.c | 479 ++
> > 6 files changed, 518 insertions(+), 1 deletion(-)
> > create mode 100644 libavcodec/libxevd.c
> >
> > diff --git a/configure b/configure
> > index e2370a23bb..cae3b666a5 100755
> > --- a/configure
> > +++ b/configure
> > @@ -293,6 +293,7 @@ External library support:
> > --enable-libx264 enable H.264 encoding via x264 [no]
> > --enable-libx265 enable HEVC encoding via x265 [no]
> > --enable-libxeve enable EVC encoding via libxeve [no]
> > + --enable-libxevd enable EVC decoding via libxevd [no]
> > --enable-libxavs enable AVS encoding via xavs [no]
> > --enable-libxavs2enable AVS2 encoding via xavs2 [no]
> > --enable-libxcb enable X11 grabbing using XCB [autodetect]
> > @@ -1904,6 +1905,7 @@ EXTERNAL_LIBRARY_LIST="
> > libvorbis
> > libvpx
> > libwebp
> > +libxevd
> > libxeve
> > libxml2
> > libzimg
> > @@ -3460,6 +3462,7 @@ libx265_encoder_deps="libx265"
> > libx265_encoder_select="atsc_a53"
> > libxavs_encoder_deps="libxavs"
> > libxavs2_encoder_deps="libxavs2"
> > +libxevd_decoder_deps="libxevd"
> > libxeve_encoder_deps="libxeve"
> > libxvid_encoder_deps="libxvid"
> > libzvbi_teletext_decoder_deps="libzvbi"
> > @@ -6835,6 +6838,7 @@ enabled libx265 && require_pkg_config
> libx265 x265 x265.h x265_api_get
> >require_cpp_condition libx265 x265.h
"X265_BUILD >= 89"
> > 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
> > enabled libxeve && require_pkg_config libxeve "xeve >=
0.4.3" "xeve.h"
> xeve_encode
> > enabled libxvid && require libxvid xvid.h xvid_global
-lxvidcore
> > enabled libzimg && require_pkg_config libzimg "zimg >=
2.7.0" zimg.h
> zimg_get_api_version
> > diff --git a/doc/decoders.texi b/doc/decoders.texi index
> > 09b8314dd2..6311af229f 100644
> > --- a/doc/decoders.texi
> > +++ b/doc/decoders.texi
> > @@ -130,6 +130,30 @@ Set amount of frame threads to use during
> > decoding. The default value is 0 (auto
> >
> > @end table
> >
> > +@section libxevd
> > +
> > +eXtra-fast Essential Video Decoder (XEVD) MPEG-5 EVC decoder wrapper.
> > +
> > +This decoder requires the presence of the libxevd headers and library
> > +during configuration. You need to explicitly configure the build with
> > +@option{--enable-libxevd}.
> > +
> > +The xevd project website is at
> @url{https://protect2.fireeye.com/v1/url?k=b6ce3a07-d7452f31-b6cfb148-
> 74fe485cbff1-251589a888281453=1=49c754eb-4416-4e31-90e9-
> ee8e7d469d1f=https%3A%2F%2Fgithub.com%2Fmpeg5%2Fxevd%257D.
> > +
> > +@subsection Options
> > +
> > +The following options are supported by the libxevd wrapper.
> > +The xevd-equivalent options or values are listed in parentheses for
easy
> migration.
> > +
> > +To get a more accurate and extensive documentation of the libxevd
> > +options, invoke the command @code{xevd_app --help} or consult the
libxevd
> documentation.
> > +
> > +@table @option
> > +@item threads (@emph{threads})
> > +Force to use a
Re: [FFmpeg-devel] [PATCH] Add NVENC "Maximum encoded slice size in bytes" for H.264/HEVC codecs.
On Thu, 27 Jul 2023 at 13:09, Timo Rothenpieler wrote: > Looks sensible to me. > I'm curious, what is the use case for this mode? > The classical use-case for this feature is to fit a slice in a UDP packet for RTP streaming. 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 5/6] fftools: avradio support
ons 2023-07-26 klockan 12:37 +0200 skrev Michael Niedermayer: > But what my goal after > having some fun with SDR is, is to > serve the end user. And here iam > trying to make it possible that "FFmpeg based" players and tools > can use SDR. Which tools and players? > For FFmpeg using a C or C++ libraray for some parts of SDR like DAB > is something that makes sense and i plan to go that route. But beyond > that I simply do not understand how your suggestions would server > end users End users are already served by existing programs like gqrx. My point is rather about the sanity of our developers, and of downstream developers. The fact that you don't mention downstream projects by name tells me that you haven't asked them /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 v3 2/2] lavf: add prores bitstream demuxer and muxer
On 7/27/2023 9:16 AM, hung kuishing wrote: > Let me briefly describe what I needed at that time: > I have another prores encoder and another mov muxer, what I need to do are: > 1. use "another mov muxer" to encapsulate prores bitstream generated by > ffmpeg. > 2. use ffmpeg to encapsulate prores bitstream generated by "another prores > encoder" . > > I know I can implement them by calling the ffmpeg api, but how can I > implement them by ffmpeg tool? > So, I developed these patches. So this format was created as a weird hack to enable the ffmpeg CLI to be jammed into such a workflow. My NAK remains. - 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] Add NVENC "Maximum encoded slice size in bytes" for H.264/HEVC codecs.
Looks sensible to me. I'm curious, what is the use case for this mode? ___ 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 5/5] fftools/ffmpeg: support applying container level cropping
On 7/27/2023 8:13 AM, Anton Khirnov wrote:
Quoting Tomas Härdin (2023-07-26)
tis 2023-07-25 klockan 14:09 -0300 skrev James Almer:
Signed-off-by: James Almer
---
Now inserting a filter into the graph.
This looks useful for MXF
+ { "apply_cropping", HAS_ARG | OPT_BOOL | OPT_SPEC |
+ OPT_EXPERT |
OPT_INPUT, { .off =
OFFSET(apply_cropping) },
+ "Apply frame cropping instead of exporting it" },
Hm. Can this be applied automatically for ffplay? When transcoding I
expect the typical use case is to not crop and to carry the metadata
over.
Why? We do apply decoder cropping by default. There's also no guarantee
that your container will be able to write it, so it seems better to
apply it by default.
I agree. In a transcoding scenario you want to apply the container level
cropping since it's defining a subrectangle with the actual content
meant for display, so why force the encoder handle pixels that were
meant to be discarded to being with, potentially ruining encoding
quality for neighboring pixels?
For codec copy scenarios though, the side data is going to be copied, so
Tomas' idea of having muxers report they support writing it is good
either way.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 0/7] webp: add support for animated WebP decoding
Am 25.07.23 um 22:14 schrieb James Zern: On Tue, Jul 25, 2023 at 1:58 AM Thilo Borgmann wrote: Still images fixed from v2. Now includes a fate test for animated webp. Patch 5/7 is still there for making changes in lavc/webp reviewable but shall be stashed when pushing. -Thilo Josef Zlomek (2): libavcodec/webp: add support for animated WebP decoding libavformat/webp: add WebP demuxer Thilo Borgmann (5): avcodec/webp: move definitions into header avcodec/webp: remove unused definitions avcodec/webp_parser: parse each frame into one packet avcodec/webp: make init_canvas_frame static fate: add test for animated WebP Changelog | 2 + doc/demuxers.texi | 28 + libavcodec/codec_desc.c | 3 +- libavcodec/version.h| 2 +- libavcodec/webp.c | 715 +-- libavcodec/webp.h | 38 + libavcodec/webp_parser.c| 130 ++-- libavformat/Makefile| 1 + libavformat/allformats.c| 1 + libavformat/version.h | 2 +- libavformat/webpdec.c | 733 tests/fate/image.mak| 3 + tests/ref/fate/exif-image-webp | 12 +- tests/ref/fate/webp-anim| 22 + tests/ref/fate/webp-rgb-lena-lossless | 2 +- tests/ref/fate/webp-rgb-lena-lossless-rgb24 | 2 +- tests/ref/fate/webp-rgb-lossless| 2 +- tests/ref/fate/webp-rgb-lossy-q80 | 2 +- tests/ref/fate/webp-rgba-lossless | 2 +- tests/ref/fate/webp-rgba-lossy-q80 | 2 +- 20 files changed, 1589 insertions(+), 115 deletions(-) create mode 100644 libavcodec/webp.h create mode 100644 libavformat/webpdec.c create mode 100644 tests/ref/fate/webp-anim This series is lgtm. There are still a few edge cases where 1) the 'Canvas change detected' warning will be triggered with valid files, As long as the canvas in frame threading is bound to a ThreadFrame, we can't reallocate for changes. Wouldn't want to touch that until the new threading is all done. 2) corrupt / truncated files will produce output where they would fail with libwebp and We might bail out as well though AFAICT we usually try to decode whatever might be possible. 3) I see quite a few "[webp @ 0x7f5530008c00] Multiple ff_thread_finish_setup() calls", not sure if that's expected. Which sample you're looking at? If I can reproduce this, I'll look at it. The other things I'd keep as they are. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 5/5] fftools/ffmpeg: support applying container level cropping
Quoting Tomas Härdin (2023-07-26)
> tis 2023-07-25 klockan 14:09 -0300 skrev James Almer:
> > Signed-off-by: James Almer
> > ---
> > Now inserting a filter into the graph.
>
> This looks useful for MXF
>
> > + { "apply_cropping", HAS_ARG | OPT_BOOL | OPT_SPEC |
> > + OPT_EXPERT |
> > OPT_INPUT, { .off =
> > OFFSET(apply_cropping) },
> > + "Apply frame cropping instead of exporting it" },
>
> Hm. Can this be applied automatically for ffplay? When transcoding I
> expect the typical use case is to not crop and to carry the metadata
> over.
Why? We do apply decoder cropping by default. There's also no guarantee
that your container will be able to write it, so it seems better to
apply it by default.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 5/5] fftools/ffmpeg: support applying container level cropping
ons 2023-07-26 klockan 19:11 -0300 skrev James Almer:
> On 7/26/2023 6:42 PM, Tomas Härdin wrote:
> > tis 2023-07-25 klockan 14:09 -0300 skrev James Almer:
> > > Signed-off-by: James Almer
> > > ---
> > > Now inserting a filter into the graph.
> >
> > This looks useful for MXF
> >
> > > + { "apply_cropping", HAS_ARG | OPT_BOOL | OPT_SPEC |
> > > + OPT_EXPERT |
> > > OPT_INPUT, { .off =
> > > OFFSET(apply_cropping) },
> > > + "Apply frame cropping instead of exporting it" },
> >
> > Hm. Can this be applied automatically for ffplay? When transcoding
> > I
> > expect the typical use case is to not crop and to carry the
> > metadata
> > over. MXF -> MOV for example. But when playing I expect one just
> > wants
> > to see the display rectangle.
>
> You want it to be disabled by default on ffmpeg but enabled in
> ffplay?
Yeah that seems like it'd be most user friendly. Then 3rd party
developers can look at ffplay to see how to apply it in their own
players. mpv and vlc come to mind
> For the latter, something like:
>
> > diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> > index 5212ad053e..217fc3e45a 100644
> > --- a/fftools/ffplay.c
> > +++ b/fftools/ffplay.c
> > @@ -36,6 +36,7 @@
> > #include "libavutil/eval.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/pixdesc.h"
> > +#include "libavutil/intreadwrite.h"
> > #include "libavutil/imgutils.h"
> > #include "libavutil/dict.h"
> > #include "libavutil/fifo.h"
> > @@ -346,6 +347,7 @@ static const char **vfilters_list = NULL;
> > static int nb_vfilters = 0;
> > static char *afilters = NULL;
> > static int autorotate = 1;
> > +static int apply_cropping = 1;
> > static int find_stream_info = 1;
> > static int filter_nbthreads = 0;
> >
> > @@ -1922,6 +1924,27 @@ static int
> > configure_video_filters(AVFilterGraph *graph, VideoState *is, const
> > c
> > }
> > }
> >
> > + if (apply_cropping) {
> > + size_t cropping_size;
> > + uint8_t *cropping = av_stream_get_side_data(is->video_st,
> > AV_PKT_DATA_FRAME_CROPPING, _size);
> > +
> > + if (cropping && cropping_size == sizeof(uint32_t) * 4) {
> > + char crop_buf[64];
> > + int top = AV_RL32(cropping + 0);
> > + int bottom = AV_RL32(cropping + 4);
> > + int left = AV_RL32(cropping + 8);
> > + int right = AV_RL32(cropping + 12);
> > +
> > + if (top < 0 || bottom < 0 || left < 0 || right < 0) {
> > + ret = AVERROR(EINVAL);
> > + goto fail;
> > + }
> > +
> > + snprintf(crop_buf, sizeof(crop_buf), "w=iw-%d-%d:h=ih-
> > %d-%d", left, right, top, bottom);
> > + INSERT_FILT("crop", crop_buf);
> > + }
> > + }
> > +
> > if ((ret = configure_filtergraph(graph, vfilters, filt_src,
> > last_filter)) < 0)
> > goto fail;
> >
> > @@ -3593,6 +3616,7 @@ static const OptionDef options[] = {
> > { "scodec", HAS_ARG | OPT_STRING | OPT_EXPERT, {
> > _codec_name }, "force subtitle decoder", "decoder_name" },
> > { "vcodec", HAS_ARG | OPT_STRING | OPT_EXPERT, {
> > _codec_name }, "force video decoder", "decoder_name" },
> > { "autorotate", OPT_BOOL, { }, "automatically
> > rotate video", "" },
> > + { "apply_cropping", OPT_BOOL, { _cropping }, "apply
> > frame cropping", "" },
> > { "find_stream_info", OPT_BOOL | OPT_INPUT | OPT_EXPERT, {
> > _stream_info },
> > "read and decode the streams to fill missing information
> > with heuristics" },
> > { "filter_threads", HAS_ARG | OPT_INT | OPT_EXPERT, {
> > _nbthreads }, "number of filter threads per graph" },
>
> Would do it, but i don't know if this affects the AVCodecContext
> option
> of the same name too or not (to apply or not bitstream level
> cropping,
> like the h264 one, which is obviously enabled by default).
Right, there's multiple levels of cropping
> To have it disabled on ffmpeg by default, i think the following would
> work (on top of this patch):
>
> > diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
> > index 1209cf2046..a37c136cf9 100644
> > --- a/fftools/ffmpeg_demux.c
> > +++ b/fftools/ffmpeg_demux.c
> > @@ -1086,10 +1086,11 @@ static int ist_add(const OptionsContext *o,
> > Demuxer *d, AVStream *st)
> > ist->autorotate = 1;
> > MATCH_PER_STREAM_OPT(autorotate, i, ist->autorotate, ic, st);
> >
> > - ist->apply_cropping = 1;
> > + ist->apply_cropping = -1;
> > MATCH_PER_STREAM_OPT(apply_cropping, i, ist->apply_cropping,
> > ic, st);
> >
> > - av_dict_set_int(>g->codec_opts, "apply_cropping", ist-
> > >apply_cropping, 0);
> > + if (ist->apply_cropping >= 0)
> > + av_dict_set_int(>g->codec_opts, "apply_cropping", ist-
> > >apply_cropping, 0);
> >
> > MATCH_PER_STREAM_OPT(codec_tags, str, codec_tag, ic, st);
> > if (codec_tag) {
> > diff --git a/fftools/ffmpeg_filter.c
[FFmpeg-devel] [PATCH] Replace br return with ret
This patch changes the return instruction in the tr_32x4 macro from br to ret. On devices that support BTI a landing pad is required when branching with br, or the instruction can be replaced with a ret. The change fixes fate-hevc-hdr-vivid-metadata when on hardware with BTI support. Signed-off-by: Casey Smalley --- libavcodec/aarch64/hevcdsp_idct_neon.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S b/libavcodec/aarch64/hevcdsp_idct_neon.S index b7f23386a4..eab2add9e8 100644 --- a/libavcodec/aarch64/hevcdsp_idct_neon.S +++ b/libavcodec/aarch64/hevcdsp_idct_neon.S @@ -791,7 +791,7 @@ function func_tr_32x4_\name add x3, x11, #(32 + 3 * 64) scale_store \shift -br x10 +ret x10 endfunc .endm -- 2.40.1 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ___ 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] lavu/tx: disable odd-length RDFTs
Jul 25, 2023, 11:41 by d...@lynne.ee: > They're presently broken, and not really needed anywhere. > They can be fixed at a later date, but for > > Patch attached. > They *were* already disabled, as intended, in the original code. I must've had an error in my code which caused them to show up. This specific patch is dropped. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] lavf: add prores bitstream demuxer and muxer
> From: ffmpeg-devel On Behalf Of > Andreas Rheinhardt > Sent: Thursday, July 27, 2023 1:11 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] lavf: add prores bitstream > demuxer and muxer > > hung kuishing: > >> From: ffmpeg-devel On Behalf > Of > >> Derek Buitenhuis > >> Sent: Wednesday, July 26, 2023 8:55 PM > >> To: ffmpeg-devel@ffmpeg.org > >> Subject: Re: [FFmpeg-devel] [PATCH v3 2/2] lavf: add prores > bitstream > >> demuxer and muxer > >> > >> On 7/26/2023 10:28 AM, hung kuishing wrote: > >>> Signed-off-by: clarkh > >>> --- > >>> libavformat/Makefile | 2 ++ > >>> libavformat/allformats.c | 2 ++ > >>> libavformat/proresdec.c | 66 > >> > >>> libavformat/rawenc.c | 13 > >>> 4 files changed, 83 insertions(+) > >>> create mode 100644 libavformat/proresdec.c > >> > >> At this point I am giving this a strong NAK. > >> > >> Both my initial comment[1] and subsequent comment[2] about the > first > >> one being ignore, have been ignored. It is a simple question. > > > > Sorry for not replying to your question in time! > > This patch originated from a need in my work to wrap the ProRes > bitstream generated by ffmpeg into another mov wrapper. > > So there are no files in the wild for this? Then there is no point in this. Or > is this something that other mov wrappers (you meant muxers!?) > accept? > (Couldn't you just have used e.g. nut (or even mov itself) to temporarily > store the ProRes data and then pipe this to to the foreign > muxer?) Hi, Andreas Rheinhardt: Let me briefly describe what I needed at that time: I have another prores encoder and another mov muxer, what I need to do are: 1. use "another mov muxer" to encapsulate prores bitstream generated by ffmpeg. 2. use ffmpeg to encapsulate prores bitstream generated by "another prores encoder" . I know I can implement them by calling the ffmpeg api, but how can I implement them by ffmpeg tool? So, I developed these patches. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: use avio operation instead of pb->buf_ptr use
Hendrik Leppkes 于2023年7月27日周四 14:47写道：
Hi Hendrik,
>
> On Thu, Jul 27, 2023 at 4:38 AM Steven Liu wrote:
> >
> > fix segfaults:
> > READ of size 1 at 0x610003b7 thread T0
> > #0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
> > #1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
> > #2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
> > #3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
> > #4 0x71d158 in avformat_find_stream_info
> > ffmpeg/libavformat/demux.c:2634:15
> > #5 0x4c821b in LLVMFuzzerTestOneInput
> > ffmpeg/tools/target_dem_fuzzer.c:206:11
> >
> > Signed-off-by: Steven Liu
> > ---
> > libavformat/flvdec.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> > index 3fe21622f7..003e4d7691 100644
> > --- a/libavformat/flvdec.c
> > +++ b/libavformat/flvdec.c
> > @@ -313,8 +313,9 @@ static int flv_same_video_codec(AVFormatContext *s,
> > AVCodecParameters *vpar, int
> > return 1;
> >
> > if (flv->exheader) {
> > -uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
> > -uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
> > codec_id_str[1] << 16 | codec_id_str[0] << 24;
> > +int64_t pos = avio_tell(s->pb);
> > +uint32_t codec_id = avio_rb32(s->pb);
> > +avio_seek(s->pb, pos, SEEK_SET);
> > switch(codec_id) {
> > case MKBETAG('h', 'v', 'c', '1'):
> > return vpar->codec_id == AV_CODEC_ID_HEVC;
>
> You don't need to store the position, just do a relative seek
> backwards by 4 bytes.
> I would also recommend to include a call to ffio_ensure_seekback so it
> works with streams.
Thanks for your suggestions.
i have resubmit patch v2:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230727073142.64813-1...@chinaffmpeg.org/
>
> eg. something like this:
> ffio_ensure_seekback(s->pb, 4);
> avio_rb32(s->pb);
> avio_seek(s->pb, -4, SEEK_CUR);
>
> Add appropriate error checking, in particular for ffio_ensure_seekback, etc.
>
> - Hendrik
> ___
> 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".
Thanks
Steven
___
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] avformat/flvdec: use avio operation instead of pb->buf_ptr use
check ensure seekback 4 bytes before read 4 bytes from pb,
and seek back 4 byte from current position after read 4 bytes.
fix segfaults:
READ of size 1 at 0x610003b7 thread T0
#0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
#1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
#2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
#3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
#4 0x71d158 in avformat_find_stream_info ffmpeg/libavformat/demux.c:2634:15
#5 0x4c821b in LLVMFuzzerTestOneInput
ffmpeg/tools/target_dem_fuzzer.c:206:11
Signed-off-by: Steven Liu
---
libavformat/flvdec.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 3fe21622f7..38f34567dd 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -35,6 +35,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/mathematics.h"
#include "avformat.h"
+#include "avio_internal.h"
#include "demux.h"
#include "internal.h"
#include "flv.h"
@@ -313,8 +314,14 @@ static int flv_same_video_codec(AVFormatContext *s,
AVCodecParameters *vpar, int
return 1;
if (flv->exheader) {
-uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
-uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
codec_id_str[1] << 16 | codec_id_str[0] << 24;
+uint32_t codec_id = 0;
+int ret = ffio_ensure_seekback(s->pb, 4);
+if (ret < 0) {
+av_log(s, AV_LOG_WARNING, "Could not ensure seekback, because %s",
av_err2str(ret));
+return 0;
+}
+codec_id = avio_rb32(s->pb);
+avio_seek(s->pb, -4, SEEK_CUR);
switch(codec_id) {
case MKBETAG('h', 'v', 'c', '1'):
return vpar->codec_id == AV_CODEC_ID_HEVC;
--
2.40.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/flvdec: use avio operation instead of pb->buf_ptr use
On Thu, Jul 27, 2023 at 4:38 AM Steven Liu wrote:
>
> fix segfaults:
> READ of size 1 at 0x610003b7 thread T0
> #0 0x7f928d in flv_same_video_codec ffmpeg/libavformat/flvdec.c:317:29
> #1 0x7f928d in flv_read_packet ffmpeg/libavformat/flvdec.c:1177
> #2 0x6ff32f in ff_read_packet ffmpeg/libavformat/demux.c:575:15
> #3 0x70a2fd in read_frame_internal ffmpeg/libavformat/demux.c:1263:15
> #4 0x71d158 in avformat_find_stream_info
> ffmpeg/libavformat/demux.c:2634:15
> #5 0x4c821b in LLVMFuzzerTestOneInput
> ffmpeg/tools/target_dem_fuzzer.c:206:11
>
> Signed-off-by: Steven Liu
> ---
> libavformat/flvdec.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
> index 3fe21622f7..003e4d7691 100644
> --- a/libavformat/flvdec.c
> +++ b/libavformat/flvdec.c
> @@ -313,8 +313,9 @@ static int flv_same_video_codec(AVFormatContext *s,
> AVCodecParameters *vpar, int
> return 1;
>
> if (flv->exheader) {
> -uint8_t *codec_id_str = (uint8_t *)s->pb->buf_ptr;
> -uint32_t codec_id = codec_id_str[3] | codec_id_str[2] << 8 |
> codec_id_str[1] << 16 | codec_id_str[0] << 24;
> +int64_t pos = avio_tell(s->pb);
> +uint32_t codec_id = avio_rb32(s->pb);
> +avio_seek(s->pb, pos, SEEK_SET);
> switch(codec_id) {
> case MKBETAG('h', 'v', 'c', '1'):
> return vpar->codec_id == AV_CODEC_ID_HEVC;
You don't need to store the position, just do a relative seek
backwards by 4 bytes.
I would also recommend to include a call to ffio_ensure_seekback so it
works with streams.
eg. something like this:
ffio_ensure_seekback(s->pb, 4);
avio_rb32(s->pb);
avio_seek(s->pb, -4, SEEK_CUR);
Add appropriate error checking, in particular for ffio_ensure_seekback, etc.
- Hendrik
___
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".
