[FFmpeg-devel] [PATCH] all: Replace if (ARCH_FOO) checks by #if ARCH_FOO
This is more spec-compliant because it does not rely on dead-code elimination by the compiler. Especially MSVC has problems with this, as can be seen in https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/296373.html or https://ffmpeg.org/pipermail/ffmpeg-devel/2022-May/297022.html This commit does not eliminate every instance where we rely on the dead code elimination: It only tackles branching to the initialization of arch-specific dsp code, not e.g. all uses of CONFIG_ and HAVE_ checks. But maybe it is already enough to compile FFmpeg with MSVC with whole-programm-optimizations enabled (if one does not disable too many components). Signed-off-by: Andreas Rheinhardt --- libavcodec/aacdec_template.c | 5 ++-- libavcodec/aacenc.c | 5 ++-- libavcodec/aacpsdsp_template.c| 17 ++- libavcodec/aacsbr_template.c | 5 ++-- libavcodec/ac3dsp.c | 18 ++- libavcodec/alacdsp.c | 5 ++-- libavcodec/audiodsp.c | 13 libavcodec/blockdsp.c | 21 ++--- libavcodec/bswapdsp.c | 5 ++-- libavcodec/cavsdsp.c | 5 ++-- libavcodec/cfhddsp.c | 5 ++-- libavcodec/cfhdencdsp.c | 5 ++-- libavcodec/dcadsp.c | 5 ++-- libavcodec/dct.c | 5 ++-- libavcodec/dirac_dwt.c| 4 ++- libavcodec/diracdsp.c | 5 ++-- libavcodec/dnxhdenc.c | 5 ++-- libavcodec/exrdsp.c | 5 ++-- libavcodec/fdctdsp.c | 9 +++--- libavcodec/fft_template.c | 13 +--- libavcodec/flacdsp.c | 9 +++--- libavcodec/fmtconvert.c | 17 ++- libavcodec/g722dsp.c | 9 +++--- libavcodec/h263dsp.c | 9 +++--- libavcodec/h264chroma.c | 25 libavcodec/h264dsp.c | 19 libavcodec/h264pred.c | 21 ++--- libavcodec/h264qpel.c | 25 libavcodec/hevcdsp.c | 25 libavcodec/hevcpred.c | 5 ++-- libavcodec/hpeldsp.c | 29 +- libavcodec/huffyuvdsp.c | 5 ++-- libavcodec/huffyuvencdsp.c| 5 ++-- libavcodec/idctdsp.c | 38 --- libavcodec/jpeg2000dsp.c | 5 ++-- libavcodec/lossless_audiodsp.c| 13 libavcodec/lossless_videodsp.c| 9 +++--- libavcodec/lossless_videoencdsp.c | 5 ++-- libavcodec/lpc.c | 5 ++-- libavcodec/mdct15.c | 5 ++-- libavcodec/me_cmp.c | 21 ++--- libavcodec/mlpdsp.c | 9 +++--- libavcodec/mpegaudiodsp.c | 18 +++ libavcodec/mpegvideo.c| 21 ++--- libavcodec/mpegvideo_enc.c| 5 ++-- libavcodec/mpegvideodsp.c | 9 +++--- libavcodec/mpegvideoencdsp.c | 17 ++- libavcodec/opus_pvq.c | 5 ++-- libavcodec/opusdsp.c | 10 +++ libavcodec/pixblockdsp.c | 25 libavcodec/pngdsp.c | 5 ++-- libavcodec/proresdsp.c| 5 ++-- libavcodec/qpeldsp.c | 9 +++--- libavcodec/rdft.c | 4 ++- libavcodec/rv34dsp.c | 9 +++--- libavcodec/rv40dsp.c | 13 libavcodec/sbcdsp.c | 9 +++--- libavcodec/sbrdsp_template.c | 17 ++- libavcodec/svq1enc.c | 9 +++--- libavcodec/synth_filter.c | 13 libavcodec/takdsp.c | 5 ++-- libavcodec/ttadsp.c | 5 ++-- libavcodec/ttaencdsp.c| 5 ++-- libavcodec/utvideodsp.c | 5 ++-- libavcodec/v210dec_init.h | 5 ++-- libavcodec/v210enc_init.h | 5 ++-- libavcodec/vc1dsp.c | 25 libavcodec/videodsp.c | 25 libavcodec/vorbisdsp.c| 17 ++- libavcodec/vp3dsp.c | 17 ++- libavcodec/vp56dsp.c | 9 +++--- libavcodec/vp8dsp.c | 38 --- libavcodec/vp9dsp.c | 16 ++ libavcodec/wmv2dsp.c | 5 ++-- libavcodec/x86/mdct15_init.c | 6 ++-- libavcodec/xvididct.c | 9 +++--- libavfilter/af_afirdsp.h | 5 ++-- libavfilter/af_anlmdn.c | 5 ++-- libavfilter/af_volume.c | 5 ++-- libavfilter/avf_showcqt.c | 5 ++-- libavfilter/colorspacedsp.c | 5 ++-- libavfilter/scene_sad.c | 5 ++-- libavfilter/vf_atadenoise.c | 5 ++-- libavfilter/vf_blend_init.h | 5 ++-- libavfilter/vf_bwdif.c| 5 ++-- libavfilter/vf_eq.h | 5 ++-- libavfilter/vf_framerate.c| 5 ++-- libavfilter/vf_fspp.c | 5 ++-- libavfilter/vf_gblur_init.h | 5 ++-- libavfilter/vf_gradfun.c
Re: [FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c: Remove MAX_PATH limit
> -Original Message- > From: ffmpeg-devel On Behalf Of > Stephen Hutchinson > Sent: Sunday, June 12, 2022 4:15 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c: > Remove MAX_PATH limit > > On 6/11/22 1:01 PM, nil-admir...@mailo.com wrote: > >> Why not use the AviSynth mechanism that allows to supply a UTF-8 > string? > >> > >> > https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852 > d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481 > > > > Was not aware such a mechanism exists. > > > > Commit dates back to 10 April 2017, first release supporting it is, > apparently, Avisynth+ r2487-MT: > https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT. > > > > A remark in > https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L > 844 says: > > > > /* On Windows, FFmpeg supports AviSynth interface version 6 or > higher. > > * This includes AviSynth 2.6 RC1 or higher, and AviSynth+ r1718 > or higher, > > * and excludes 2.5 and the 2.6 alphas. */ > > > > Support for plain AviSynth will have to be dropped. > > Presumably, the original manifest idea, parsed down to only using it > to > force FFmpeg into UTF-8, would be sufficient for this, right? As This is a change that would affect ffmpeg behavior at a global level, just for the sake of accommodating for a single 3rd party library (and even: only some ancient versions of it). > as AviSynth inherits that from FFmpeg, UTF-8 strings would be > pervasive > and both A) the utf8 parameter would not need to be used and B) 2.6 > would work just fine with it, transparently. > The Windows API does have a SetConsoleCP function. If that > accomplishes > the same effect as the manifest idea, that would be simpler, but it > probably would need to be located somewhere *other* than the AviSynth > demuxer. ffmpeg does not interact with AviSynth via console interface. AFAIU, it uses AviSynth in-process loading it via an API instead: val = avs_library.avs_invoke(avs->env, "Import", arg, 0); Those functions like SetConsoleCP and SetConsoleOutputCP, have no effect on the current process, it's only about console pipe communication with child (cli) processes. The manifest approach is too invasive IMO, as laid out before. At least with regards to AviSynthPlus versions since two years ago, we're not talking about long paths anymore. AviSynthPlus is using the same prefixing approach for long paths that we have employed in ffmpeg as well, now. The only question is whether we supply the script/path argument to AviSynthPlus as Ansi or UTF-8 string. It will handle long paths in both cases. The only difference is that when we're converting a UTF-8 path to an Ansi codepage, it might become an invalid path when the projection would be ambiguous. It's been like that all the time before - nothing new about it. There are functions available to check the version: avs_get_version, avs_check_version, So - in case that requiring AviSynthPlus from 2020 as a minimum would be undesirable, it should be possible to find out at runtime whether the loaded AviSynth supports the UTF8 parameter or not and set the invoke parameters accordingly. Best regards, softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/ffmpeg: fix typo in VCD creation example
On 2022-06-12 12:45 am, Marton Balint wrote:
Fixes ticket #9753.
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 51515c2cb8..d943f4d6f5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -624,21 +624,21 @@ The parameters set for each target are as follows.
@var{pal}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x288 -r 25
--codec:v mpeg1video -g 15 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 15 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@var{ntsc}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x240 -r 3/1001
--codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@var{film}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x240 -r 24000/1001
--codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@end example
Will apply.
Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c: Remove MAX_PATH limit
On 6/11/22 1:01 PM, nil-admir...@mailo.com wrote: Why not use the AviSynth mechanism that allows to supply a UTF-8 string? https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481 Was not aware such a mechanism exists. Commit dates back to 10 April 2017, first release supporting it is, apparently, Avisynth+ r2487-MT: https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT. A remark in https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L844 says: /* On Windows, FFmpeg supports AviSynth interface version 6 or higher. * This includes AviSynth 2.6 RC1 or higher, and AviSynth+ r1718 or higher, * and excludes 2.5 and the 2.6 alphas. */ Support for plain AviSynth will have to be dropped. Presumably, the original manifest idea, parsed down to only using it to force FFmpeg into UTF-8, would be sufficient for this, right? As long as AviSynth inherits that from FFmpeg, UTF-8 strings would be pervasive and both A) the utf8 parameter would not need to be used and B) 2.6 would work just fine with it, transparently. The Windows API does have a SetConsoleCP function. If that accomplishes the same effect as the manifest idea, that would be simpler, but it probably would need to be located somewhere *other* than the AviSynth demuxer. And while it might work for the fftools themselves, does it also work for usage of the libraries directly in applications that may not be console apps? Barring that, if/else checks to ensure that A) IsWindowsVersionOrGreater is at least 1903 A1) If yes, go to B A2) If no, use the existing logic B) If yes, GetACP to check that it's UTF8 B1) If yes, the Import call stays the same as it is now, no utf8 parameter B2) If no, that's where things get complicated: C1) Use the no result to tell it to then force UTF-8 mode with SetConsoleCP, if that actually works for what we need it to do. Then don't use the utf8 parameter. C2) Use avs_get_version to detect an incompatible version of AviSynth and gracefully exit with a message about upgrading to a supported version of AviSynth+, before then using the utf8 parameter for real. C3) Use avs_get_version, but if it's not a new enough version, just fall back to the logic that exists now, where 2.6 may or may not work just because the system may or may not be already set to UTF-8. C2 should really be considered a last resort IMO, because it's an artificial limit and doesn't actually have anything to do with the AviSynth API. The reason is that the utf8 parameter being discussed here is not part of the AviSynth API, it's an option handed to one of the script-level functions that avs_invoke (which is the actual API call there) is using. On the other hand, configure checks for https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L844 die "ERROR: AviSynth+ header version must be >= 3.7.1" so probably plain AviSynth and AviSynth+ below r2489-MT are already unsupported. The header version check there isn't because of old versions of AviSynth(+) being unsupported (as far as the demuxer is concerned, anyway). 3.7.1 is still API compatible with 2.6 in all the functions the demuxer uses that are shared between them. The additional Plus-specific functionality is enabled with runtime checks, so if you don't use the newer header, it will fail to build, but you can run 2.6 without problems even when using the newer header to compile the demuxer. ___ 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 5/5] swresample/resample: Remove unnecessary emms_c
The last MMX code in swresample has just been removed.
Signed-off-by: Andreas Rheinhardt
---
libswresample/resample.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libswresample/resample.c b/libswresample/resample.c
index 9c5b7fee72..8f9efc3f21 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -497,8 +497,6 @@ static int multiple_resample(ResampleContext *c, AudioData
*dst, int dst_size, A
}
}
-emms_c();
-
if (c->compensation_distance) {
c->compensation_distance -= dst_size;
if (!c->compensation_distance) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/5] swresample/x86/resample: Remove obsolete MMXEXT functions
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT, SSE and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2). So given that the only systems which benefit
from the MMXEXT resamplers (which are overridden by SSE2)
are truely ancient 32bit x86s they are removed.
Signed-off-by: Andreas Rheinhardt
---
libswresample/x86/resample.asm| 5 -
libswresample/x86/resample_init.c | 5 -
2 files changed, 10 deletions(-)
diff --git a/libswresample/x86/resample.asm b/libswresample/x86/resample.asm
index 7107cf9d42..6c3dc28703 100644
--- a/libswresample/x86/resample.asm
+++ b/libswresample/x86/resample.asm
@@ -594,11 +594,6 @@ INIT_XMM fma4
RESAMPLE_FNS float, 4, 2, s, pf_1
%endif
-%if ARCH_X86_32
-INIT_MMX mmxext
-RESAMPLE_FNS int16, 2, 1
-%endif
-
INIT_XMM sse2
RESAMPLE_FNS int16, 2, 1
%if HAVE_XOP_EXTERNAL
diff --git a/libswresample/x86/resample_init.c
b/libswresample/x86/resample_init.c
index 32c080ea4c..d13ccd4833 100644
--- a/libswresample/x86/resample_init.c
+++ b/libswresample/x86/resample_init.c
@@ -35,7 +35,6 @@ int ff_resample_common_##type##_##opt(ResampleContext *c,
void *dst, \
int ff_resample_linear_##type##_##opt(ResampleContext *c, void *dst, \
const void *src, int sz, int upd)
-RESAMPLE_FUNCS(int16, mmxext);
RESAMPLE_FUNCS(int16, sse2);
RESAMPLE_FUNCS(int16, xop);
RESAMPLE_FUNCS(float, sse);
@@ -52,10 +51,6 @@ av_cold void swri_resample_dsp_x86_init(ResampleContext *c)
switch(c->format){
case AV_SAMPLE_FMT_S16P:
-if (ARCH_X86_32 && EXTERNAL_MMXEXT(mm_flags)) {
-c->dsp.resample_linear = ff_resample_linear_int16_mmxext;
-c->dsp.resample_common = ff_resample_common_int16_mmxext;
-}
if (EXTERNAL_SSE2(mm_flags)) {
c->dsp.resample_linear = ff_resample_linear_int16_sse2;
c->dsp.resample_common = ff_resample_common_int16_sse2;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] swresample/x86/rematrix: Remove obsolete MMX functions
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt
---
libswresample/x86/rematrix.asm| 6 --
libswresample/x86/rematrix_init.c | 5 -
2 files changed, 11 deletions(-)
diff --git a/libswresample/x86/rematrix.asm b/libswresample/x86/rematrix.asm
index 7984b9a729..968010701e 100644
--- a/libswresample/x86/rematrix.asm
+++ b/libswresample/x86/rematrix.asm
@@ -223,12 +223,6 @@ mix_2_1_int16_u_int %+ SUFFIX:
%endmacro
-INIT_MMX mmx
-MIX1_INT16 u
-MIX1_INT16 a
-MIX2_INT16 u
-MIX2_INT16 a
-
INIT_XMM sse
MIX2_FLT u
MIX2_FLT a
diff --git a/libswresample/x86/rematrix_init.c
b/libswresample/x86/rematrix_init.c
index 0608c74e7f..b6ed38bf67 100644
--- a/libswresample/x86/rematrix_init.c
+++ b/libswresample/x86/rematrix_init.c
@@ -28,7 +28,6 @@ mix_2_1_func_type ff_mix_2_1_a_## type ## _ ## simd;
D(float, sse)
D(float, avx)
-D(int16, mmx)
D(int16, sse2)
av_cold int swri_rematrix_init_x86(struct SwrContext *s){
@@ -43,10 +42,6 @@ av_cold int swri_rematrix_init_x86(struct SwrContext *s){
s->mix_2_1_simd = NULL;
if (s->midbuf.fmt == AV_SAMPLE_FMT_S16P){
-if(EXTERNAL_MMX(mm_flags)) {
-s->mix_1_1_simd = ff_mix_1_1_a_int16_mmx;
-s->mix_2_1_simd = ff_mix_2_1_a_int16_mmx;
-}
if(EXTERNAL_SSE2(mm_flags)) {
s->mix_1_1_simd = ff_mix_1_1_a_int16_sse2;
s->mix_2_1_simd = ff_mix_2_1_a_int16_sse2;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/5] swresample/x86/audio_convert: Remove obsolete MMX functions
x64 always has MMX, MMXEXT, SSE and SSE2 and this means
that some functions for MMX, MMXEXT and 3dnow are always
overridden by other functions (unless one e.g. explicitly
disables SSE2) for x64. So given that the only systems that
benefit from these functions are truely ancient 32bit x86s
they are removed.
Signed-off-by: Andreas Rheinhardt
---
libswresample/x86/audio_convert.asm| 9 -
libswresample/x86/audio_convert_init.c | 9 +
2 files changed, 1 insertion(+), 17 deletions(-)
diff --git a/libswresample/x86/audio_convert.asm
b/libswresample/x86/audio_convert.asm
index d441636d3c..d6d6a81495 100644
--- a/libswresample/x86/audio_convert.asm
+++ b/libswresample/x86/audio_convert.asm
@@ -608,15 +608,6 @@ pack_8ch_%2_to_%1_u_int %+ SUFFIX:
%macro NOP_N 0-6
%endmacro
-INIT_MMX mmx
-CONV int32, int16, u, 2, 1, INT16_TO_INT32_N, NOP_N
-CONV int32, int16, a, 2, 1, INT16_TO_INT32_N, NOP_N
-CONV int16, int32, u, 1, 2, INT32_TO_INT16_N, NOP_N
-CONV int16, int32, a, 1, 2, INT32_TO_INT16_N, NOP_N
-
-PACK_6CH float, float, u, 2, 2, 0, NOP_N, NOP_N
-PACK_6CH float, float, a, 2, 2, 0, NOP_N, NOP_N
-
INIT_XMM sse
PACK_6CH float, float, u, 2, 2, 7, NOP_N, NOP_N
PACK_6CH float, float, a, 2, 2, 7, NOP_N, NOP_N
diff --git a/libswresample/x86/audio_convert_init.c
b/libswresample/x86/audio_convert_init.c
index a7d5ab89f8..f6d36f9ca6 100644
--- a/libswresample/x86/audio_convert_init.c
+++ b/libswresample/x86/audio_convert_init.c
@@ -26,7 +26,7 @@
#define PROTO(pre, in, out, cap) void ff ## pre ## in## _to_ ##out## _a_
##cap(uint8_t **dst, const uint8_t **src, int len);
#define PROTO2(pre, out, cap) PROTO(pre, int16, out, cap) PROTO(pre, int32,
out, cap) PROTO(pre, float, out, cap)
#define PROTO3(pre, cap) PROTO2(pre, int16, cap) PROTO2(pre, int32, cap)
PROTO2(pre, float, cap)
-#define PROTO4(pre) PROTO3(pre, mmx) PROTO3(pre, sse) PROTO3(pre, sse2)
PROTO3(pre, ssse3) PROTO3(pre, sse4) PROTO3(pre, avx) PROTO3(pre, avx2)
+#define PROTO4(pre) PROTO3(pre, sse) PROTO3(pre, sse2) PROTO3(pre, ssse3)
PROTO3(pre, sse4) PROTO3(pre, avx) PROTO3(pre, avx2)
PROTO4(_)
PROTO4(_pack_2ch_)
PROTO4(_pack_6ch_)
@@ -52,15 +52,8 @@ av_cold void swri_audio_convert_init_x86(struct AudioConvert
*ac,
ac->simd_f = ff_int32_to_int16_a_ ## cap;\
}
-MULTI_CAPS_FUNC(MMX, mmx)
MULTI_CAPS_FUNC(SSE2, sse2)
-if(EXTERNAL_MMX(mm_flags)) {
-if(channels == 6) {
-if( out_fmt == AV_SAMPLE_FMT_FLT && in_fmt ==
AV_SAMPLE_FMT_FLTP || out_fmt == AV_SAMPLE_FMT_S32 && in_fmt ==
AV_SAMPLE_FMT_S32P)
-ac->simd_f = ff_pack_6ch_float_to_float_a_mmx;
-}
-}
if(EXTERNAL_SSE(mm_flags)) {
if(channels == 6) {
if( out_fmt == AV_SAMPLE_FMT_FLT && in_fmt ==
AV_SAMPLE_FMT_FLTP || out_fmt == AV_SAMPLE_FMT_S32 && in_fmt ==
AV_SAMPLE_FMT_S32P)
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] swresample/resample: Properly empty MMX state
There is a x86-32 MMXEXT implementation for resampling
planar 16bit data. multiple_resample() therefore calls
emms_c() if it thinks that this needed. And this is bad:
1. It is a maintenance nightmare because changes to the
x86 resample DSP code would necessitate changes to the check
whether to call emms_c().
2. The return value of av_get_cpu_flags() does not tell
whether the MMX DSP functions are in use, as they could
have been overridden by av_force_cpu_flags().
3. The MMX DSP functions will never be overridden in case of
an x86-32 build with --disable-sse2. In this scenario lots of
resampling tests (like swr-resample_exact_lin_async-s16p-8000-48000)
fail because the cpuflags indicate that SSE2 is available
(presuming that the test is run on a CPU with SSE2).
4. The check includes a call to av_get_cpu_flags(). This is not
optimized away for arches other than x86-32.
5. The check takes about as much time as emms_c() itself,
making it pointless.
This commit therefore removes the check and calls emms_c()
unconditionally (it is a no-op for non-x86).
Signed-off-by: Andreas Rheinhardt
---
The reason I don't add an ARCH_X86_32 check is that I intend
to remove this emms_c() again shortly. I have just updated
my branch [1] that removes obsolete MMX(EXT) by a commit that
removes the MMXEXT resampling functions that are the cause
of this issue. A follow-up commit then removes the emms_c()
completely.
[1]: https://github.com/mkver/FFmpeg/commits/mmx2
libswresample/resample.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libswresample/resample.c b/libswresample/resample.c
index f1ec77f54b..9c5b7fee72 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -452,9 +452,6 @@ static int set_compensation(ResampleContext *c, int
sample_delta, int compensati
static int multiple_resample(ResampleContext *c, AudioData *dst, int dst_size,
AudioData *src, int src_size, int *consumed){
int i;
-int av_unused mm_flags = av_get_cpu_flags();
-int need_emms = c->format == AV_SAMPLE_FMT_S16P && ARCH_X86_32 &&
-(mm_flags & (AV_CPU_FLAG_MMX2 | AV_CPU_FLAG_SSE2)) ==
AV_CPU_FLAG_MMX2;
int64_t max_src_size = (INT64_MAX/2 / c->phase_count) / c->src_incr;
if (c->compensation_distance)
@@ -500,8 +497,7 @@ static int multiple_resample(ResampleContext *c, AudioData
*dst, int dst_size, A
}
}
-if(need_emms)
-emms_c();
+emms_c();
if (c->compensation_distance) {
c->compensation_distance -= dst_size;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 00/41] Stop including superseded functions for x64
Andreas Rheinhardt:
> x64 requires MMX, MMXEXT, SSE and SSE2; yet there is no shortage
> of code like the following:
>
> if (EXTERNAL_MMX(cpu_flags)) {
> c->ssd_int8_vs_int16 = ff_ssd_int8_vs_int16_mmx;
> }
> if (EXTERNAL_SSE2(cpu_flags)) {
> c->ssd_int8_vs_int16 = ff_ssd_int8_vs_int16_sse2;
> }
>
> Given that SSE2 is always present on x64, the only way
> for the mmx version to be chosen in the above example
> is if SSE2 has been disabled either at compile-time
> or at runtime, i.e. it is never used unless one shoots
> oneself in the foot.
> This patchset therefore disables such functions for x64
> by #if'ing them away; x86 has not been affected. This
> saves about 140KB.
>
> (Another way to handle this would be to remove every function
> that would be overridden if one had a processor capable of
> MMX, MMXEXT, SSE and SSE2. x86 processors not fulfilling
> this requirement (which are truely ancient nowadays)
> would still work, but would be slower, i.e. they would be treated
> as second-class citizens. This would have the advantage of
> avoiding #ifs and would lighten x86 binaries of code that is
> not used at all by the overwhelming majority of users.
> I'll update this patchset if it is preferred to do it that way.)
>
I have now implemented this other way mentioned above (i.e. removing
stuff that is overridden if SSE2 is available altogether also for
x86-32); the result can be seen here:
https://github.com/mkver/FFmpeg/commits/mmx2
I prefer this to the old version because of the reduced complexity which
dwarfs the potential to slow down some ancient systems a bit (if these
ancient systems use an up-to-date FFmpeg which is quite unlikely).
Furthermore, some of the MMX scale functions that are removed are
buggy/not bixexact. See
https://github.com/mkver/FFmpeg/commit/c5513ad962100040601b5eba0042692a740ac50a
(or shall I post these patches?)
Is anyone against this removal?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/ffmpeg: fix typo in VCD creation example
Fixes ticket #9753.
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 51515c2cb8..d943f4d6f5 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -624,21 +624,21 @@ The parameters set for each target are as follows.
@var{pal}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x288 -r 25
--codec:v mpeg1video -g 15 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 15 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@var{ntsc}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x240 -r 3/1001
--codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@var{film}:
-f vcd -muxrate 1411200 -muxpreload 0.44 -packetsize 2324
-s 352x240 -r 24000/1001
--codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150v -minrate:v 1150k
-bufsize:v 327680
+-codec:v mpeg1video -g 18 -b:v 1150k -maxrate:v 1150k -minrate:v 1150k
-bufsize:v 327680
-ar 44100 -ac 2
-codec:a mp2 -b:a 224k
@end example
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avdevice/pulse_audio_dec: deprecate frame_size option
It does not do anything. Frame sizes can be controlled by using fragment_size.
Signed-off-by: Marton Balint
---
doc/indevs.texi | 2 +-
libavdevice/pulse_audio_dec.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 1141da26d1..8a198c4b44 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1289,7 +1289,7 @@ Specify the samplerate in Hz, by default 48kHz is used.
Specify the channels in use, by default 2 (stereo) is set.
@item frame_size
-Specify the number of bytes per frame, by default it is set to 1024.
+This option does nothing and is deprecated.
@item fragment_size
Specify the size in bytes of the minimal buffering fragment in PulseAudio, it
diff --git a/libavdevice/pulse_audio_dec.c b/libavdevice/pulse_audio_dec.c
index c780d607a0..8d440c5621 100644
--- a/libavdevice/pulse_audio_dec.c
+++ b/libavdevice/pulse_audio_dec.c
@@ -371,6 +371,7 @@ static int pulse_get_device_list(AVFormatContext *h,
AVDeviceInfoList *device_li
#define OFFSET(a) offsetof(PulseData, a)
#define D AV_OPT_FLAG_DECODING_PARAM
+#define DEPR AV_OPT_FLAG_DEPRECATED
static const AVOption options[] = {
{ "server","set PulseAudio server",
OFFSET(server),AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, D },
@@ -378,7 +379,7 @@ static const AVOption options[] = {
{ "stream_name", "set stream description",
OFFSET(stream_name), AV_OPT_TYPE_STRING, {.str = "record"}, 0, 0, D },
{ "sample_rate", "set sample rate in Hz",
OFFSET(sample_rate), AV_OPT_TYPE_INT,{.i64 = 48000},1, INT_MAX, D },
{ "channels", "set number of audio channels",
OFFSET(channels), AV_OPT_TYPE_INT,{.i64 = 2},1, INT_MAX, D },
-{ "frame_size","set number of bytes per frame",
OFFSET(frame_size),AV_OPT_TYPE_INT,{.i64 = 1024}, 1, INT_MAX, D },
+{ "frame_size","set number of bytes per frame",
OFFSET(frame_size),AV_OPT_TYPE_INT,{.i64 = 1024}, 1, INT_MAX, D |
DEPR },
{ "fragment_size", "set buffering size, affects latency and cpu usage",
OFFSET(fragment_size), AV_OPT_TYPE_INT,{.i64 = -1}, -1, INT_MAX, D },
{ "wallclock", "set the initial pts using the current time",
OFFSET(wallclock), AV_OPT_TYPE_INT,{.i64 = 1}, -1, 1, D },
{ NULL },
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/3] avdevice/pulse_audio_dec: reduce default fragment size
Reduces default fragment size from the pulse audio default of 2 sec to 50 ms.
This also has an effect on the size of the returned frames, which will be
around 50 ms as well, making timestamps more accurate.
This should fix the regression in ticket #9776.
Pulseaudio timestamps for monitor sources are still pretty inaccurate for me,
but I don't see how else should we query latencies from the library.
Signed-off-by: Marton Balint
---
doc/indevs.texi | 4 ++--
libavdevice/pulse_audio_dec.c | 7 ++-
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 9d8020311a..1141da26d1 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@ -1292,8 +1292,8 @@ Specify the channels in use, by default 2 (stereo) is set.
Specify the number of bytes per frame, by default it is set to 1024.
@item fragment_size
-Specify the minimal buffering fragment in PulseAudio, it will affect the
-audio latency. By default it is unset.
+Specify the size in bytes of the minimal buffering fragment in PulseAudio, it
+will affect the audio latency. By default it is set to 50 ms amount of data.
@item wallclock
Set the initial PTS using the current time. Default is 1.
diff --git a/libavdevice/pulse_audio_dec.c b/libavdevice/pulse_audio_dec.c
index ed094fd250..c780d607a0 100644
--- a/libavdevice/pulse_audio_dec.c
+++ b/libavdevice/pulse_audio_dec.c
@@ -162,7 +162,12 @@ static av_cold int pulse_read_header(AVFormatContext *s)
return AVERROR(ENOMEM);
}
-attr.fragsize = pd->fragment_size;
+if (pd->fragment_size == -1) {
+// 50 ms fragments/latency by default seem good enough
+attr.fragsize = av_rescale(pa_frame_size(), pd->sample_rate, 20);
+} else {
+attr.fragsize = pd->fragment_size;
+}
if (s->url[0] != '\0' && strcmp(s->url, "default"))
device = s->url;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/3] Revert "avdevice/pulse_audio_dec: only set adjust latency flag if fragment_size is not set"
This reverts commit 7f059a250bb7bcbf7bba537c1a059a5934413035.
Apparently adjusting latency makes a difference even if fragment size is
specifed.
Signed-off-by: Marton Balint
---
libavdevice/pulse_audio_dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/pulse_audio_dec.c b/libavdevice/pulse_audio_dec.c
index a33d1afd1f..ed094fd250 100644
--- a/libavdevice/pulse_audio_dec.c
+++ b/libavdevice/pulse_audio_dec.c
@@ -220,7 +220,7 @@ static av_cold int pulse_read_header(AVFormatContext *s)
ret = pa_stream_connect_record(pd->stream, device, ,
PA_STREAM_INTERPOLATE_TIMING
-| (pd->fragment_size == -1 ?
PA_STREAM_ADJUST_LATENCY : 0)
+|PA_STREAM_ADJUST_LATENCY
|PA_STREAM_AUTO_TIMING_UPDATE);
if (ret < 0) {
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v13 2/4] libavformat/avisynth.c: Remove MAX_PATH limit
> Why not use the AviSynth mechanism that allows to supply a UTF-8 string? > > https://github.com/AviSynth/AviSynthPlus/blob/c377916aa4146d2f4386852d91dc177d49103c16/avs_core/core/parser/script.cpp#L477-L481 Was not aware such a mechanism exists. Commit dates back to 10 April 2017, first release supporting it is, apparently, Avisynth+ r2487-MT: https://github.com/pinterf/AviSynthPlus/releases/tag/r2489-MT. A remark in https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L844 says: /* On Windows, FFmpeg supports AviSynth interface version 6 or higher. * This includes AviSynth 2.6 RC1 or higher, and AviSynth+ r1718 or higher, * and excludes 2.5 and the 2.6 alphas. */ Support for plain AviSynth will have to be dropped. On the other hand, configure checks for https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/avisynth.c#L844 > die "ERROR: AviSynth+ header version must be >= 3.7.1" so probably plain AviSynth and AviSynth+ below r2489-MT are already unsupported. ___ 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] libavutil/dovi_meta: Add nlq_pivots to AVDOVIDataMapping
quietvoid:
> The NLQ pivots are not documented but should be present
> in the header for profile 7 RPU format.
> It has been verified using Dolby's verification toolkit.
>
> Also implemented the parsing in libavcodec/dovi_rpu.c.
> And added the info to ffprobe and showinfo.
> ---
> fftools/ffprobe.c | 4
> libavcodec/dovi_rpu.c | 7 +++
> libavfilter/vf_showinfo.c | 8
> libavutil/dovi_meta.h | 1 +
> 4 files changed, 20 insertions(+)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index c44297c1fa..63eb9b32ae 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -1934,6 +1934,10 @@ static void print_dovi_metadata(WriterContext *w,
> const AVDOVIMetadata *dovi)
> break;
> }
>
> +if (mapping->nlq_method_idc != AV_DOVI_NLQ_NONE) {
> +print_list_fmt("nlq_pivots", "%"PRIu16, 2,
> mapping->nlq_pivots[idx]);
> +}
> +
> print_int("num_x_partitions", mapping->num_x_partitions);
> print_int("num_y_partitions", mapping->num_y_partitions);
>
> diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> index a87562c8a3..17837eb845 100644
> --- a/libavcodec/dovi_rpu.c
> +++ b/libavcodec/dovi_rpu.c
> @@ -315,7 +315,14 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t
> *rpu, size_t rpu_size)
> }
>
> if (use_nlq) {
> +int nlq_pivot = 0;
> vdr->mapping.nlq_method_idc = get_bits(gb, 3);
> +
> +for (int i = 0; i < 2; i++) {
> +nlq_pivot += get_bits(gb, hdr->bl_bit_depth);
> +vdr->mapping.nlq_pivots[i] = av_clip_uint16(nlq_pivot);
> +}
> +
> /**
> * The patent mentions another legal value, NLQ_MU_LAW, but it's
> * not documented anywhere how to parse or apply that type of
> NLQ.
> diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> index 12d39310ef..2148d202b1 100644
> --- a/libavfilter/vf_showinfo.c
> +++ b/libavfilter/vf_showinfo.c
> @@ -543,6 +543,14 @@ static void dump_dovi_metadata(AVFilterContext *ctx,
> const AVFrameSideData *sd)
> av_log(ctx, AV_LOG_INFO, "mapping_color_space=%"PRIu8"; ",
> mapping->mapping_color_space);
> av_log(ctx, AV_LOG_INFO, "mapping_chroma_format_idc=%"PRIu8"; ",
> mapping->mapping_chroma_format_idc);
> av_log(ctx, AV_LOG_INFO, "nlq_method_idc=%d; ", (int)
> mapping->nlq_method_idc);
> +
> +if (mapping->nlq_method_idc != AV_DOVI_NLQ_NONE) {
> +av_log(ctx, AV_LOG_INFO, "nlq_pivots={ ");
> +for (int i = 0; i < 2; i++)
> +av_log(ctx, AV_LOG_INFO, "%"PRIu16" ", mapping->nlq_pivots[i]);
> +av_log(ctx, AV_LOG_INFO, "}; ");
> +}
> +
> av_log(ctx, AV_LOG_INFO, "num_x_partitions=%"PRIu32"; ",
> mapping->num_x_partitions);
> av_log(ctx, AV_LOG_INFO, "num_y_partitions=%"PRIu32"\n",
> mapping->num_y_partitions);
>
> diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
> index 3d11e02bff..c7c5ba721f 100644
> --- a/libavutil/dovi_meta.h
> +++ b/libavutil/dovi_meta.h
> @@ -144,6 +144,7 @@ typedef struct AVDOVIDataMapping {
>
> /* Non-linear inverse quantization */
> enum AVDOVINLQMethod nlq_method_idc;
> +uint16_t nlq_pivots[2]; /* nlq_pred_pivot_value */
> uint32_t num_x_partitions;
> uint32_t num_y_partitions;
> AVDOVINLQParams nlq[3]; /* per component */
This breaks ABI. New fields must be added at the end.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] fate: Add test to parse profile 7 DOVI RPU
--- tests/fate/hevc.mak | 3 + tests/ref/fate/hevc-dovi-profile7-rpu | 296 ++ 2 files changed, 299 insertions(+) create mode 100644 tests/ref/fate/hevc-dovi-profile7-rpu diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak index 2f16e3a29f..549436cb39 100644 --- a/tests/fate/hevc.mak +++ b/tests/fate/hevc.mak @@ -254,6 +254,9 @@ FATE_HEVC-$(call FRAMECRC, HEVC, HEVC) += fate-hevc-cabac-tudepth fate-hevc-small422chroma: CMD = framecrc -flags unaligned -i $(TARGET_SAMPLES)/hevc/food.hevc -pix_fmt yuv422p10le -vf scale FATE_HEVC-$(call FRAMECRC, HEVC, HEVC, HEVC_PARSER SCALE_FILTER) += fate-hevc-small422chroma +fate-hevc-dovi-profile7-rpu: CMD = probeframes -show_entries frame=side_data_list -select_streams 1 -read_intervals "%+\#2" $(TARGET_SAMPLES)/mov/dovi-p7.mp4 +FATE_HEVC_FFPROBE-$(call DEMDEC, MOV, HEVC) += fate-hevc-dovi-profile7-rpu + FATE_SAMPLES_AVCONV += $(FATE_HEVC-yes) FATE_SAMPLES_FFPROBE += $(FATE_HEVC_FFPROBE-yes) diff --git a/tests/ref/fate/hevc-dovi-profile7-rpu b/tests/ref/fate/hevc-dovi-profile7-rpu new file mode 100644 index 00..7fa5d20f01 --- /dev/null +++ b/tests/ref/fate/hevc-dovi-profile7-rpu @@ -0,0 +1,296 @@ +[FRAME] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=34000/5 +red_y=16000/5 +green_x=13250/5 +green_y=34500/5 +blue_x=7500/5 +blue_y=3000/5 +white_point_x=15635/5 +white_point_y=16450/5 +min_luminance=1/1 +max_luminance=1/1 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Content light level metadata +max_content=1000 +max_average=400 +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Dolby Vision RPU Data +[/SIDE_DATA] +[SIDE_DATA] +side_data_type=Dolby Vision Metadata +rpu_type=2 +rpu_format=18 +vdr_rpu_profile=1 +vdr_rpu_level=0 +chroma_resampling_explicit_filter_flag=0 +coef_data_type=0 +coef_log2_denom=23 +vdr_rpu_normalized_idc=1 +bl_video_full_range_flag=0 +bl_bit_depth=10 +el_bit_depth=10 +vdr_bit_depth=12 +spatial_resampling_filter_flag=0 +el_spatial_resampling_filter_flag=1 +disable_residual_flag=0 +vdr_rpu_id=0 +mapping_color_space=0 +mapping_chroma_format_idc=0 +nlq_method_idc=0 +nlq_method_idc_name=linear_dz +nlq_pivots=0 1023 +num_x_partitions=1 +num_y_partitions=1 +[COMPONENT] +pivots=0 128 256 384 512 640 768 896 1023 +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +[SECTION] +mapping_idc=0 +mapping_idc_name=polynomial +poly_order=1 +poly_coef=0 8388608 +[/SECTION] +nlq_offset=512 +vdr_in_max=1048576 +linear_deadzone_slope=2048 +linear_deadzone_threshold=0 +[/COMPONENT] +[COMPONENT] +pivots=0 1023 +[SECTION] +mapping_idc=1 +mapping_idc_name=mmr +mmr_order=3 +mmr_constant=448998 +mmr_coef=-1262056 8122466 -1703266 1622123 808554 -829469 -13459 801251 694657 3697830 -1819391 -772917 -654425 78034 -181321 -324811 -2213356 -716030 761880 365184 2545494 +[/SECTION] +nlq_offset=512 +vdr_in_max=1048576 +linear_deadzone_slope=2048 +linear_deadzone_threshold=0 +[/COMPONENT] +[COMPONENT] +pivots=0 1023 +[SECTION] +mapping_idc=1 +mapping_idc_name=mmr +mmr_order=3 +mmr_constant=30364 +mmr_coef=-1369971 645159 9055254 -106426 2546351 -2246880 672220 1356576 1789054 -3311517 -1372035 -4554569 -548063 722319 57239 -2130348 3956345 1480062 -1696575 3919674 3414157 +[/SECTION] +nlq_offset=512 +vdr_in_max=1048576 +linear_deadzone_slope=2048 +linear_deadzone_threshold=0 +[/COMPONENT] +dm_metadata_id=0 +scene_refresh_flag=0 +ycc_to_rgb_matrix=9574/8192 0/8192 13802/8192 9574/8192 -1540/8192 -5348/8192 9574/8192 17610/8192 0/8192 +ycc_to_rgb_offset=16777216/268435456 134217728/268435456 134217728/268435456 +rgb_to_lms_matrix=7222/16384 8771/16384 390/16384 2654/16384 12430/16384 1300/16384 0/16384 422/16384 15962/16384 +signal_eotf=65535 +signal_eotf_param0=0 +signal_eotf_param1=0 +signal_eotf_param2=0 +signal_bit_depth=12 +signal_color_space=0 +signal_chroma_format=0 +signal_full_range_flag=1 +source_min_pq=7 +source_max_pq=3079 +source_diagonal=42 +[/SIDE_DATA] +[/FRAME] +[FRAME] +[SIDE_DATA] +side_data_type=Mastering display metadata +red_x=34000/5 +red_y=16000/5 +green_x=13250/5 +green_y=34500/5 +blue_x=7500/5 +blue_y=3000/5 +white_point_x=15635/5 +white_point_y=16450/5 +min_luminance=1/1 +max_luminance=1/1 +[/SIDE_DATA] +[SIDE_DATA]
[FFmpeg-devel] [PATCH 1/2] libavutil/dovi_meta: Add nlq_pivots to AVDOVIDataMapping
The NLQ pivots are not documented but should be present
in the header for profile 7 RPU format.
It has been verified using Dolby's verification toolkit.
Also implemented the parsing in libavcodec/dovi_rpu.c.
And added the info to ffprobe and showinfo.
---
fftools/ffprobe.c | 4
libavcodec/dovi_rpu.c | 7 +++
libavfilter/vf_showinfo.c | 8
libavutil/dovi_meta.h | 1 +
4 files changed, 20 insertions(+)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index c44297c1fa..63eb9b32ae 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -1934,6 +1934,10 @@ static void print_dovi_metadata(WriterContext *w, const
AVDOVIMetadata *dovi)
break;
}
+if (mapping->nlq_method_idc != AV_DOVI_NLQ_NONE) {
+print_list_fmt("nlq_pivots", "%"PRIu16, 2,
mapping->nlq_pivots[idx]);
+}
+
print_int("num_x_partitions", mapping->num_x_partitions);
print_int("num_y_partitions", mapping->num_y_partitions);
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
index a87562c8a3..17837eb845 100644
--- a/libavcodec/dovi_rpu.c
+++ b/libavcodec/dovi_rpu.c
@@ -315,7 +315,14 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t *rpu,
size_t rpu_size)
}
if (use_nlq) {
+int nlq_pivot = 0;
vdr->mapping.nlq_method_idc = get_bits(gb, 3);
+
+for (int i = 0; i < 2; i++) {
+nlq_pivot += get_bits(gb, hdr->bl_bit_depth);
+vdr->mapping.nlq_pivots[i] = av_clip_uint16(nlq_pivot);
+}
+
/**
* The patent mentions another legal value, NLQ_MU_LAW, but it's
* not documented anywhere how to parse or apply that type of NLQ.
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 12d39310ef..2148d202b1 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -543,6 +543,14 @@ static void dump_dovi_metadata(AVFilterContext *ctx, const
AVFrameSideData *sd)
av_log(ctx, AV_LOG_INFO, "mapping_color_space=%"PRIu8"; ",
mapping->mapping_color_space);
av_log(ctx, AV_LOG_INFO, "mapping_chroma_format_idc=%"PRIu8"; ",
mapping->mapping_chroma_format_idc);
av_log(ctx, AV_LOG_INFO, "nlq_method_idc=%d; ", (int)
mapping->nlq_method_idc);
+
+if (mapping->nlq_method_idc != AV_DOVI_NLQ_NONE) {
+av_log(ctx, AV_LOG_INFO, "nlq_pivots={ ");
+for (int i = 0; i < 2; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu16" ", mapping->nlq_pivots[i]);
+av_log(ctx, AV_LOG_INFO, "}; ");
+}
+
av_log(ctx, AV_LOG_INFO, "num_x_partitions=%"PRIu32"; ",
mapping->num_x_partitions);
av_log(ctx, AV_LOG_INFO, "num_y_partitions=%"PRIu32"\n",
mapping->num_y_partitions);
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index 3d11e02bff..c7c5ba721f 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -144,6 +144,7 @@ typedef struct AVDOVIDataMapping {
/* Non-linear inverse quantization */
enum AVDOVINLQMethod nlq_method_idc;
+uint16_t nlq_pivots[2]; /* nlq_pred_pivot_value */
uint32_t num_x_partitions;
uint32_t num_y_partitions;
AVDOVINLQParams nlq[3]; /* per component */
--
2.36.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/2] DOVI: Add NLQ pivots to AVDOVIDataMapping
The NLQ pivots are not documented but should be present
in the header for profile 7 RPU format.
It has been verified using Dolby's verification toolkit.
With the pivots parsed, the parsed values for
num_{x,y}_partitions are correct and usually equal to 1.
quietvoid (2):
libavutil/dovi_meta: Add nlq_pivots to AVDOVIDataMapping
fate: Add test to parse profile 7 DOVI RPU
fftools/ffprobe.c | 4 +
libavcodec/dovi_rpu.c | 7 +
libavfilter/vf_showinfo.c | 8 +
libavutil/dovi_meta.h | 1 +
tests/fate/hevc.mak | 3 +
tests/ref/fate/hevc-dovi-profile7-rpu | 296 ++
6 files changed, 319 insertions(+)
create mode 100644 tests/ref/fate/hevc-dovi-profile7-rpu
--
2.36.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] swscale: add NV16 input/output
On Fri, Jun 10, 2022 at 04:11:10PM +0200, Matthieu Bouron wrote: > On Thu, Jun 2, 2022 at 9:13 PM Michael Niedermayer > wrote: > > > On Wed, Jun 01, 2022 at 10:33:37PM +0200, Matthieu Bouron wrote: > > > --- > > > libswscale/input.c | 1 + > > > libswscale/utils.c | 1 + > > > libswscale/version.h | 2 +- > > > tests/ref/fate/filter-pixdesc-nv16 | 1 + > > > tests/ref/fate/filter-pixfmts-copy | 1 + > > > tests/ref/fate/filter-pixfmts-crop | 1 + > > > tests/ref/fate/filter-pixfmts-field | 1 + > > > tests/ref/fate/filter-pixfmts-fieldorder | 1 + > > > tests/ref/fate/filter-pixfmts-hflip | 1 + > > > tests/ref/fate/filter-pixfmts-il | 1 + > > > tests/ref/fate/filter-pixfmts-null | 1 + > > > tests/ref/fate/filter-pixfmts-pad| 1 + > > > tests/ref/fate/filter-pixfmts-scale | 1 + > > > tests/ref/fate/filter-pixfmts-vflip | 1 + > > > 14 files changed, 14 insertions(+), 1 deletion(-) > > > create mode 100644 tests/ref/fate/filter-pixdesc-nv16 > > > > > Sorry for the late reply > > > > has this been tested ? (various scaled and non scaled) variants ? > > > > I only tested the non scaled variant using the command line doing multiple > round trips to/from nv16. > Is there a particular test procedure to validate every variants ? you can test manually or use something like libswscale/tests/swscale.c [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- 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".
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
Hi On Sat, Jun 11, 2022 at 02:37:19AM +0300, Аскар Сафин wrote: > Hi. I use Debian Linux. I always capture my screen. I do this using my > own program, which takes rgb24 frames from X server and saves them > lossless in my own format. At fps 4 > (but duplicate frames are dropped). My codec is absolutely trivial > (and lossless), it is based on ideas from QOI ( > https://github.com/phoboslab/qoi ) and QOV ( > https://github.com/wide-video/qov ). > First I apply something like QOV encoding (with interframe coding) and > then compress every frame using zstd with level 8. Surprisingly such > trivial codec performs very well on my data. > It gives better compress ratio than all lossless ffmpeg codecs I tried > (x264, x265, vp9, av1, ffv1, ffvhuff, flv). > > I write this not because I want to brag. I write this because it is > possible that you will be interested in my ideas, that you will > incorporate my ideas into your code. > > ffv1 spec reads: "FFV1 is designed to support a wide range of lossless > video applications such as... screen recording..." Unfortunately, ffv1 > turned out to be bad compared to my codec > on screen recording data, so it is possible ffv1 could benefit from my ideas. > > Now let me show you some data. I have a test video named > "test-video-2022-05-16-17.mkv" in lossless x264 fullhd, which was > captured from my screen. Uncompressed PAM size is > 208,268,339,335 bytes (208.2 G). Unfortunately I cannot share it, > because it contains a lot of my personal info. Now let me show you how > different codecs perform on this file. All data > was collected with this premises: pix_fmt is rgb24, everything is > lossless, gop is 32, everything is on aws ec2 c3.4xlarge with 16 > cores, everything on Debian sid with sid's version of ffmpeg. > > Codec: x264 > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -pix_fmt rgb24 > -c:v libx264rgb -preset veryslow -qp 0 -threads 16 -g 32 /tmp/out.mkv > Size: 2506211845 (~ 2.5 G) > Time: 1218.22 > > Codec: ffv1 > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v ffv1 > -pix_fmt rgb24 -level 3 -threads 16 -g 32 -context 1 -slices 4 -coder > -2 /tmp/o.mkv > Size: 9431473324 (~9.4 G) > Time: 1125.15 > > Codec: my codec (single threaded!) > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v pam -pix_fmt > rgb24 -f image2pipe pipe: < /dev/null | /tmp/nrdy encode 8 32 > Size: 1860479127 (~1.8 G) > Time: 470.88 > > So, as you can see my codec beats ffv1 and x264 both by compress ratio > and speed. Moreover, my single-threaded codec beats other > multi-threads codecs by time. Are you interested? > If yes, I can share my code. Of course, under some permissive license. > Again: there is no any magic here, just something like QOV + zstd. > Also, I can specially extract some sample > from my videos, which doesn't contain personal info, and perform tests > on this sample and publish sample send a patch to libavcodec/ffv1*c even better, add the interframe part independant of the residual coding part so for each slice interframe can be choosen (like blank/intra, 0,0 MV, more optiond for future extension) and residual coding (current FFV1, some LZ coder, ...) why i suggest this, is because if you do, your code could become used by alot of people. OTOH if you just post ideas nothing will likely happen. There are many ideas about motion compensation and it didnt get cleanly integrated yet. Also modular implementation in ffv1 would make alot of sense as we really want to see what each individual part add compression/speed/complexity wise so the overall codebase stays reasonable clean. We wouldnt want to support 10 algorithms if only 2 really make sense) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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 2/3] avcodec/fmvc: buffer size is stride based not 4*width
On Sat, Jun 11, 2022 at 10:47:57AM +0200, Paul B Mahol wrote: > Have you actually tested this "change" ? On every file i found 6-methyl-5-hepten-2-one-CC-db_small.avi fmvcVirtualDub_small.avi skrzyzowanie4.avi fmvc-poc.avi are there any other files i should test it on ? thx [...] -- 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".
[FFmpeg-devel] [PATCH] avcodec/get_bits: declare VLC table args as const
Declaring the VLC table as const allows a caller to call get_vlc2()
with a pre-generated static const table without generating warnings
for -Wdiscarded-qualifiers.
---
libavcodec/get_bits.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index d4e9276da1..49202b0211 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -775,7 +775,7 @@ static inline const uint8_t *align_get_bits(GetBitContext
*s)
/* Return the LUT element for the given bitstream configuration. */
static inline int set_idx(GetBitContext *s, int code, int *n, int *nb_bits,
- VLC_TYPE (*table)[2])
+ const VLC_TYPE (*table)[2])
{
unsigned idx;
@@ -795,7 +795,7 @@ static inline int set_idx(GetBitContext *s, int code, int
*n, int *nb_bits,
* = (max_vlc_length + bits - 1) / bits
* @returns the code parsed or -1 if no vlc matches
*/
-static av_always_inline int get_vlc2(GetBitContext *s, VLC_TYPE (*table)[2],
+static av_always_inline int get_vlc2(GetBitContext *s, const VLC_TYPE
(*table)[2],
int bits, int max_depth)
{
#if CACHED_BITSTREAM_READER
--
2.36.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 v7] libx264: Set min build version to 158
On Thu, 9 Jun 2022, Matt Oliver wrote:
From: Matt Oliver
Was "[PATCH] libx264: Do not explicitly set X264_API_IMPORTS"
Setting X264_API_IMPORTS only affects msvc builds and it breaks
linking to static builds (although is required for shared builds).
This flag is set by x264 in its pkgconfig as required since build
158 (a615f027ed172e2dd5380e736d487aa858a0c4ff) from July 2019.
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.
The min version requirement of 158 is applied for msvc builds only.
This is also removing the check for 'libx264 without pkg-config'
which was left for compatibility reasons about 7 years ago when
the pkg-config check was introduced by commit
e06263ef1e0e172b2c76070b3dc739411af08e82.
Co-authored-by: softworkz
Signed-off-by: softworkz
Signed-off-by: Matt Oliver
Thanks, applied.
Regards,
Marton
---
libx264: Set min build version to 158
I'm submitting this patch on behalf of Matt with his permission.
There was agreement that the >= 158 version requirement should be
applied to MSVC builds only.
v2: restrict the version requirement to msvc builds
v3: fix unintended author change
v4: add missing braces
v5: fixed condition (again ;-)
v6: hope I got it now..
v7: add comment about dropping non-pkg-conf check, re-add libx262 check
Published-As:
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-30%2Fsoftworkz%2Fsubmit_x264_api_imports_matt-v7
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg
pr-ffstaging-30/softworkz/submit_x264_api_imports_matt-v7
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/30
Range-diff vs v6:
1: 47843fb51e ! 1: 3baec48834 libx264: Set min build version to 158
@@ Commit message
So this patch updates configure to require a newer x264 build that
correctly sets the imports flag.
-The requirement for 158 is applied for msvc builds only,
-no change is made for all other cases.
+The min version requirement of 158 is applied for msvc builds only.
+
+This is also removing the check for 'libx264 without pkg-config'
+which was left for compatibility reasons about 7 years ago when
+the pkg-config check was introduced by commit
+e06263ef1e0e172b2c76070b3dc739411af08e82.
Co-authored-by: softworkz
Signed-off-by: softworkz
@@ configure: enabled libvpx&& {
- { require libx264 "stdint.h x264.h" x264_encoder_encode
"-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } }
&&
- require_cpp_condition libx264 x264.h "X264_BUILD >=
118" &&
-- check_cpp_condition libx262 x264.h
"X264_MPEG2"
+enabled libx264 && check_pkg_config libx264 x264 "stdint.h x264.h"
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD >=
118" && {
+ [ "$toolchain" != "msvc" ] ||
-+ require_cpp_condition libx264 x264.h "X264_BUILD
>= 158"; }
++ require_cpp_condition libx264 x264.h "X264_BUILD >=
158"; } &&
+ check_cpp_condition libx262 x264.h
"X264_MPEG2"
enabled libx265 && require_pkg_config libx265 x265 x265.h x265_api_get
&&
require_cpp_condition libx265 x265.h "X265_BUILD
>= 70"
- enabled libxavs && require libxavs "stdint.h xavs.h" xavs_encoder_encode
"-lxavs $pthreads_extralibs $libm_extralibs"
## libavcodec/libx264.c ##
@@
configure| 8
libavcodec/libx264.c | 4
2 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 5a167613a4..3dca1c4bd3 100755
--- a/configure
+++ b/configure
@@ -6658,10 +6658,10 @@ enabled libvpx&& {
enabled libwebp && {
enabled libwebp_encoder && require_pkg_config libwebp "libwebp >=
0.2.0" webp/encode.h WebPGetEncoderVersion
enabled libwebp_anim_encoder && check_pkg_config libwebp_anim_encoder "libwebpmux
>= 0.4.0" webp/mux.h WebPAnimEncoderOptionsInit; }
-enabled libx264 && { check_pkg_config libx264 x264 "stdint.h x264.h"
x264_encoder_encode ||
- { require libx264 "stdint.h x264.h" x264_encoder_encode
"-lx264 $pthreads_extralibs $libm_extralibs" &&
- warn "using libx264 without pkg-config"; } }
&&
- require_cpp_condition libx264 x264.h "X264_BUILD >= 118"
&&
+enabled libx264 && check_pkg_config libx264 x264 "stdint.h x264.h"
x264_encoder_encode &&
+ require_cpp_condition libx264 x264.h "X264_BUILD >= 118"
&& {
+ [
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
> What about different samples? Not just single big one. I tried to pick representative sample. Which contains all kind of activities I usually do on my computer. Again: if you want, I can spend some time finding smaller samples without personal info (such that I can publish them) ___ 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] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
Op za 11 jun. 2022 01:37 schreef Аскар Сафин : > ffv1 spec reads: "FFV1 is designed to support a wide range of lossless > video applications such as... screen recording..." Unfortunately, ffv1 > turned out to be bad compared to my codec > on screen recording data, so it is possible ffv1 could benefit from my > ideas. > While the spec indeed mentions screen recording, it seems the kind of screen recording you do is probably not a use where ffv1 shines. The spec abstract starts with "This document defines FFV1, a lossless, intra-frame video encoding format." Notice "intra-frame". ffv1 does not do inter-frame decorrelation like most other codecs do. So, when compressing data with high inter-frame correlation, ffv1 doesn't do well. ffv1 does very well on for example film scans, when the presence of film grain makes inter-frame decorrelation of relatively little use. In screen captures where > 95% of the frame stays exactly the same, this approach doesn't work well indeed. ___ 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] avformat/mov: prevent potential use of uninitialized value
lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] ffmpeg: add option fps_mode
Now the `vsync` function has a better name. On the other hand, I'm curious
whether the `vsync`/`fps_mode` function is still valuable in the ffmpeg
tool source since the `fps` filter does almost the same job, but may have
less coupling?
On Sat, Jun 11, 2022 at 12:24 PM Gyan Doshi wrote:
> Pushed as 09c53a04c5892baee88872fbce3df17a00472faa
>
> On 2022-06-10 06:39 pm, Gyan Doshi wrote:
> > fps_mode sets video sync per output stream. Overrides vsync for matching
> > streams.
> >
> > vsync is deprecated.
> > ---
> > doc/ffmpeg.texi | 14 --
> > fftools/ffmpeg.c | 9 +
> > fftools/ffmpeg.h | 3 +++
> > fftools/ffmpeg_mux.c | 2 +-
> > fftools/ffmpeg_opt.c | 42 +++---
> > 5 files changed, 48 insertions(+), 22 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 0d7e1a479d..51515c2cb8 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -1618,12 +1618,14 @@ it may cause packet loss.
> > It is useful for when flow speed of output packets is important, such
> as live streaming.
> > @item -re (@emph{input})
> > Read input at native frame rate. This is equivalent to setting
> @code{-readrate 1}.
> > -@item -vsync @var{parameter}
> > -Video sync method.
> > -
> > -For compatibility reasons some of the values can be specified as
> numbers (shown
> > -in parentheses in the following table). This is deprecated and will
> stop working
> > -in the future.
> > +@item -vsync @var{parameter} (@emph{global})
> > +@itemx -fps_mode[:@var{stream_specifier}] @var{parameter}
> (@emph{output,per-stream})
> > +Set video sync method / framerate mode. vsync is applied to all output
> video streams
> > +but can be overridden for a stream by setting fps_mode. vsync is
> deprecated and will be
> > +removed in the future.
> > +
> > +For compatibility reasons some of the values for vsync can be specified
> as numbers (shown
> > +in parentheses in the following table).
> >
> > @table @option
> > @item passthrough (0)
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index a5e1bf3993..09caa3e3c4 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -3017,11 +3017,12 @@ static int
> init_output_stream_encode(OutputStream *ost, AVFrame *frame)
> >
> > if (!(enc_ctx->time_base.num && enc_ctx->time_base.den))
> > enc_ctx->time_base =
> av_buffersink_get_time_base(ost->filter->filter);
> > -if ( av_q2d(enc_ctx->time_base) < 0.001 && video_sync_method
> != VSYNC_PASSTHROUGH
> > - && (video_sync_method == VSYNC_CFR || video_sync_method ==
> VSYNC_VSCFR ||
> > - (video_sync_method == VSYNC_AUTO && !(of->format->flags
> & AVFMT_VARIABLE_FPS{
> > +if ( av_q2d(enc_ctx->time_base) < 0.001 && ost->vsync_method
> != VSYNC_PASSTHROUGH
> > + && (ost->vsync_method == VSYNC_CFR || ost->vsync_method ==
> VSYNC_VSCFR ||
> > + (ost->vsync_method == VSYNC_AUTO && !(of->format->flags
> & AVFMT_VARIABLE_FPS{
> > av_log(oc, AV_LOG_WARNING, "Frame rate very high for a
> muxer not efficiently supporting it.\n"
> > - "Please consider specifying a
> lower framerate, a different muxer or -vsync 2\n");
> > + "Please consider specifying a
> lower framerate, a different muxer or "
> > + "setting vsync/fps_mode to
> vfr\n");
> > }
> >
> > enc_ctx->width = av_buffersink_get_w(ost->filter->filter);
> > diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> > index 7326193caf..69a368b8d1 100644
> > --- a/fftools/ffmpeg.h
> > +++ b/fftools/ffmpeg.h
> > @@ -176,6 +176,8 @@ typedef struct OptionsContext {
> > intnb_qscale;
> > SpecifierOpt *forced_key_frames;
> > intnb_forced_key_frames;
> > +SpecifierOpt *fps_mode;
> > +intnb_fps_mode;
> > SpecifierOpt *force_fps;
> > intnb_force_fps;
> > SpecifierOpt *frame_aspect_ratios;
> > @@ -489,6 +491,7 @@ typedef struct OutputStream {
> > AVRational max_frame_rate;
> > enum VideoSyncMethod vsync_method;
> > int is_cfr;
> > +const char *fps_mode;
> > int force_fps;
> > int top_field_first;
> > int rotate_overridden;
> > diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
> > index 794d580635..a55fd18f8f 100644
> > --- a/fftools/ffmpeg_mux.c
> > +++ b/fftools/ffmpeg_mux.c
> > @@ -96,7 +96,7 @@ void of_write_packet(OutputFile *of, AVPacket *pkt,
> OutputStream *ost,
> > return;
> > }
> >
> > -if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> video_sync_method == VSYNC_DROP) ||
> > +if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
> ost->vsync_method == VSYNC_DROP) ||
> > (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
> audio_sync_method < 0))
> > pkt->pts = pkt->dts =
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/fmvc: buffer size is stride based not 4*width
Have you actually tested this "change" ? ___ 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 time reporting for DFPWM streams
lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Trivial codec based on QOI and zstd compresses better than all lossless ffmpeg codecs on my data from screen
On Sat, Jun 11, 2022 at 1:37 AM Аскар Сафин wrote: > Hi. I use Debian Linux. I always capture my screen. I do this using my > own program, which takes rgb24 frames from X server and saves them > lossless in my own format. At fps 4 > (but duplicate frames are dropped). My codec is absolutely trivial > (and lossless), it is based on ideas from QOI ( > https://github.com/phoboslab/qoi ) and QOV ( > https://github.com/wide-video/qov ). > First I apply something like QOV encoding (with interframe coding) and > then compress every frame using zstd with level 8. Surprisingly such > trivial codec performs very well on my data. > It gives better compress ratio than all lossless ffmpeg codecs I tried > (x264, x265, vp9, av1, ffv1, ffvhuff, flv). > > I write this not because I want to brag. I write this because it is > possible that you will be interested in my ideas, that you will > incorporate my ideas into your code. > > ffv1 spec reads: "FFV1 is designed to support a wide range of lossless > video applications such as... screen recording..." Unfortunately, ffv1 > turned out to be bad compared to my codec > on screen recording data, so it is possible ffv1 could benefit from my > ideas. > > Now let me show you some data. I have a test video named > "test-video-2022-05-16-17.mkv" in lossless x264 fullhd, which was > captured from my screen. Uncompressed PAM size is > 208,268,339,335 bytes (208.2 G). Unfortunately I cannot share it, > because it contains a lot of my personal info. Now let me show you how > different codecs perform on this file. All data > was collected with this premises: pix_fmt is rgb24, everything is > lossless, gop is 32, everything is on aws ec2 c3.4xlarge with 16 > cores, everything on Debian sid with sid's version of ffmpeg. > > Codec: x264 > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -pix_fmt rgb24 > -c:v libx264rgb -preset veryslow -qp 0 -threads 16 -g 32 /tmp/out.mkv > Size: 2506211845 (~ 2.5 G) > Time: 1218.22 > > Codec: ffv1 > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v ffv1 > -pix_fmt rgb24 -level 3 -threads 16 -g 32 -context 1 -slices 4 -coder > -2 /tmp/o.mkv > Size: 9431473324 (~9.4 G) > Time: 1125.15 > > Codec: my codec (single threaded!) > Command line: ffmpeg -loglevel warning -i /tmp/t.mkv -c:v pam -pix_fmt > rgb24 -f image2pipe pipe: < /dev/null | /tmp/nrdy encode 8 32 > Size: 1860479127 (~1.8 G) > Time: 470.88 > > So, as you can see my codec beats ffv1 and x264 both by compress ratio > and speed. Moreover, my single-threaded codec beats other > multi-threads codecs by time. Are you interested? > If yes, I can share my code. Of course, under some permissive license. > Again: there is no any magic here, just something like QOV + zstd. > Also, I can specially extract some sample > from my videos, which doesn't contain personal info, and perform tests > on this sample and publish sample > What about different samples? Not just single big one. > ___ > 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] avformat/os_support: use windows stat structs with 64bit time_t
On Sat, 11 Jun 2022, Christopher Degawa wrote: On Thu, Jun 9, 2022 at 6:22 PM softworkz wrote: From: softworkz Signed-off-by: softworkz --- avformat/os_support: use windows stat structs with 64bit time_t Signed-off-by: softworkz softwo...@hotmail.com Ping on this patch, this fixes an error with decklink due to clang++ complaining about no conversions between the two struct types Pushed this now, thanks! // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/2] avformat/mov: prevent potential use of uninitialized value
---
libavformat/mov.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d7be593a86..51c0f6f9d8 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6772,7 +6772,10 @@ static int mov_read_dfla(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
avio_rb24(pb); /* Flags */
-avio_read(pb, buf, sizeof(buf));
+if (avio_read(pb, buf, sizeof(buf)) != sizeof(buf)) {
+av_log(c->fc, AV_LOG_ERROR, "failed to read FLAC metadata block
header\n");
+return (pb->error < 0 ? pb->error : AVERROR_INVALIDDATA);
+}
flac_parse_block_header(buf, , , );
if (type != FLAC_METADATA_TYPE_STREAMINFO || size != FLAC_STREAMINFO_SIZE)
{
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/2] avformat/cafdec: Implement FLAC-in-CAF parsing
The afconvert utility shipped with MacOS supports muxing of FLAC
in CAF, see afconvert help output on a recent Mac here:
https://hydrogenaud.io/index.php?topic=122509.0 A file created
with afconvert free of copyright (licensed CC0) can be found here:
http://www.audiograaf.nl/misc_stuff/afconvert-FLAC-in-CAF.caf
This patch implements parsing of such a file
---
libavformat/caf.c| 1 +
libavformat/cafdec.c | 44
2 files changed, 45 insertions(+)
diff --git a/libavformat/caf.c b/libavformat/caf.c
index a700e4055b..a61c39fae5 100644
--- a/libavformat/caf.c
+++ b/libavformat/caf.c
@@ -46,6 +46,7 @@ const AVCodecTag ff_codec_caf_tags[] = {
{ AV_CODEC_ID_GSM, MKTAG('a','g','s','m') },
{ AV_CODEC_ID_GSM_MS, MKTAG('m','s', 0, '1') },
{ AV_CODEC_ID_ILBC,MKTAG('i','l','b','c') },
+{ AV_CODEC_ID_FLAC,MKTAG('f','l','a','c') },
{ AV_CODEC_ID_MACE3, MKTAG('M','A','C','3') },
{ AV_CODEC_ID_MACE6, MKTAG('M','A','C','6') },
{ AV_CODEC_ID_MP1, MKTAG('.','m','p','1') },
diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 168f69f20b..ced61643f8 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -32,6 +32,7 @@
#include "internal.h"
#include "isom.h"
#include "mov_chan.h"
+#include "libavcodec/flac.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/intfloat.h"
#include "libavutil/dict.h"
@@ -170,6 +171,49 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t
size)
}
avio_skip(pb, size - ALAC_NEW_KUKI);
}
+} else if (st->codecpar->codec_id == AV_CODEC_ID_FLAC) {
+int last, type, flac_metadata_size;
+uint8_t buf[4];
+/* The magic cookie format for FLAC consists mostly of an mp4 dfLa
atom. */
+if (size < (16 + FLAC_STREAMINFO_SIZE)) {
+av_log(s, AV_LOG_ERROR, "invalid FLAC magic cookie\n");
+return AVERROR_INVALIDDATA;
+}
+/* Check cookie version. */
+if (avio_r8(pb) != 0) {
+av_log(s, AV_LOG_ERROR, "unknown FLAC magic cookie\n");
+return AVERROR_INVALIDDATA;
+}
+avio_rb24(pb); /* Flags */
+/* read dfLa fourcc */
+if (avio_read(pb, buf, 4) != 4) {
+av_log(s, AV_LOG_ERROR, "failed to read FLAC magic cookie\n");
+return (pb->error < 0 ? pb->error : AVERROR_INVALIDDATA);
+}
+if (memcmp(buf,"dfLa",4)) {
+av_log(s, AV_LOG_ERROR, "invalid FLAC magic cookie\n");
+return AVERROR_INVALIDDATA;
+}
+/* Check dfLa version. */
+if (avio_r8(pb) != 0) {
+av_log(s, AV_LOG_ERROR, "unknown dfLa version\n");
+return AVERROR_INVALIDDATA;
+}
+avio_rb24(pb); /* Flags */
+if (avio_read(pb, buf, sizeof(buf)) != sizeof(buf)) {
+av_log(s, AV_LOG_ERROR, "failed to read FLAC metadata block
header\n");
+return (pb->error < 0 ? pb->error : AVERROR_INVALIDDATA);
+}
+flac_parse_block_header(buf, , , _metadata_size);
+if (type != FLAC_METADATA_TYPE_STREAMINFO || flac_metadata_size !=
FLAC_STREAMINFO_SIZE) {
+av_log(s, AV_LOG_ERROR, "STREAMINFO must be first
FLACMetadataBlock\n");
+return AVERROR_INVALIDDATA;
+}
+ret = ff_get_extradata(s, st->codecpar, pb, FLAC_STREAMINFO_SIZE);
+if (ret < 0)
+return ret;
+if (!last)
+av_log(s, AV_LOG_WARNING, "non-STREAMINFO FLACMetadataBlock(s)
ignored\n");
} else if (st->codecpar->codec_id == AV_CODEC_ID_OPUS) {
// The data layout for Opus is currently unknown, so we do not export
// extradata at all. Multichannel streams are not supported.
--
2.30.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/os_support: use windows stat structs with 64bit time_t
On Thu, Jun 9, 2022 at 6:22 PM softworkz wrote: > From: softworkz > > Signed-off-by: softworkz > --- > avformat/os_support: use windows stat structs with 64bit time_t > > Signed-off-by: softworkz softwo...@hotmail.com > > > Ping on this patch, this fixes an error with decklink due to clang++ complaining about no conversions between the two struct types ___ 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".
