[FFmpeg-devel] [PATCH] aarch64: Factorize code for CPU feature detection on Apple platforms
---
libavutil/aarch64/cpu.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/libavutil/aarch64/cpu.c b/libavutil/aarch64/cpu.c
index 7a05391343..196bdaf6b0 100644
--- a/libavutil/aarch64/cpu.c
+++ b/libavutil/aarch64/cpu.c
@@ -45,22 +45,23 @@ static int detect_flags(void)
#elif defined(__APPLE__) && HAVE_SYSCTLBYNAME
#include
+static int have_feature(const char *feature) {
+uint32_t value = 0;
+size_t size = sizeof(value);
+if (!sysctlbyname(feature, &value, &size, NULL, 0))
+return value;
+return 0;
+}
+
static int detect_flags(void)
{
-uint32_t value = 0;
-size_t size;
int flags = 0;
-size = sizeof(value);
-if (!sysctlbyname("hw.optional.arm.FEAT_DotProd", &value, &size, NULL, 0))
{
-if (value)
-flags |= AV_CPU_FLAG_DOTPROD;
-}
-size = sizeof(value);
-if (!sysctlbyname("hw.optional.arm.FEAT_I8MM", &value, &size, NULL, 0)) {
-if (value)
-flags |= AV_CPU_FLAG_I8MM;
-}
+if (have_feature("hw.optional.arm.FEAT_DotProd"))
+flags |= AV_CPU_FLAG_DOTPROD;
+if (have_feature("hw.optional.arm.FEAT_I8MM"))
+flags |= AV_CPU_FLAG_I8MM;
+
return flags;
}
--
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] lavu/attributes: add ff_ prefix to attribute_deprecated
Otherwise it might conflict with caller-defined identifiers.
ff because it is not supposed to be used by external callers.
---
doc/developer.texi | 2 +-
doc/print_options.c| 4 ++--
libavcodec/avcodec.h | 4 ++--
libavcodec/avfft.h | 30 +-
libavcodec/packet.h| 4 ++--
libavcodec/vdpau.h | 8 +++
libavfilter/avfilter.h | 4 ++--
libavformat/avformat.h | 12 +--
libavutil/attributes.h | 12 ---
libavutil/frame.h | 12 +--
libavutil/hdr_dynamic_vivid_metadata.h | 12 +--
libavutil/version.h| 1 +
12 files changed, 56 insertions(+), 49 deletions(-)
diff --git a/doc/developer.texi b/doc/developer.texi
index c86bb5820c..141139df8c 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -522,7 +522,7 @@ removing the API - this is described in @ref{Major version
bumps}.
To deprecate an API you should signal to our users that they should stop using
it. E.g. if you intend to remove struct members or functions, you should mark
-them with @code{attribute_deprecated}. When this cannot be done, it may be
+them with @code{ff_attribute_deprecated}. When this cannot be done, it may be
possible to detect the use of the deprecated API at runtime and print a warning
(though take care not to print it too often). You should also document the
deprecation (and the replacement, if applicable) in the relevant Doxygen
diff --git a/doc/print_options.c b/doc/print_options.c
index fd1cf10dc1..89df2928b8 100644
--- a/doc/print_options.c
+++ b/doc/print_options.c
@@ -35,8 +35,8 @@
#include "libavutil/opt.h"
/* Forcibly turn off deprecation warnings, which just add noise here. */
-#undef attribute_deprecated
-#define attribute_deprecated
+#undef ff_attribute_deprecated
+#define ff_attribute_deprecated
#include "libavcodec/options_table.h"
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 21fc74707f..0c1c4eec41 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -572,7 +572,7 @@ typedef struct AVCodecContext {
* - encoding: Set AVCodecContext.framerate instead
*
*/
-attribute_deprecated
+ff_attribute_deprecated
int ticks_per_frame;
#endif
@@ -2370,7 +2370,7 @@ int avcodec_open2(AVCodecContext *avctx, const AVCodec
*codec, AVDictionary **op
* multiple times is not supported anymore -- use multiple codec contexts
* instead.
*/
-attribute_deprecated
+ff_attribute_deprecated
int avcodec_close(AVCodecContext *avctx);
#endif
diff --git a/libavcodec/avfft.h b/libavcodec/avfft.h
index e3a0da1eb9..1cf1cd6df1 100644
--- a/libavcodec/avfft.h
+++ b/libavcodec/avfft.h
@@ -50,14 +50,14 @@ typedef struct FFTContext FFTContext;
* @param inverse if 0 perform the forward transform, if 1 perform the
inverse
* @deprecated use av_tx_init from libavutil/tx.h with a type of
AV_TX_FLOAT_FFT
*/
-attribute_deprecated
+ff_attribute_deprecated
FFTContext *av_fft_init(int nbits, int inverse);
/**
* Do the permutation needed BEFORE calling ff_fft_calc().
* @deprecated without replacement
*/
-attribute_deprecated
+ff_attribute_deprecated
void av_fft_permute(FFTContext *s, FFTComplex *z);
/**
@@ -65,25 +65,25 @@ void av_fft_permute(FFTContext *s, FFTComplex *z);
* input data must be permuted before. No 1.0/sqrt(n) normalization is done.
* @deprecated use the av_tx_fn value returned by av_tx_init, which also does
permutation
*/
-attribute_deprecated
+ff_attribute_deprecated
void av_fft_calc(FFTContext *s, FFTComplex *z);
-attribute_deprecated
+ff_attribute_deprecated
void av_fft_end(FFTContext *s);
/**
* @deprecated use av_tx_init from libavutil/tx.h with a type of
AV_TX_FLOAT_MDCT,
* with a flag of AV_TX_FULL_IMDCT for a replacement to av_imdct_calc.
*/
-attribute_deprecated
+ff_attribute_deprecated
FFTContext *av_mdct_init(int nbits, int inverse, double scale);
-attribute_deprecated
+ff_attribute_deprecated
void av_imdct_calc(FFTContext *s, FFTSample *output, const FFTSample *input);
-attribute_deprecated
+ff_attribute_deprecated
void av_imdct_half(FFTContext *s, FFTSample *output, const FFTSample *input);
-attribute_deprecated
+ff_attribute_deprecated
void av_mdct_calc(FFTContext *s, FFTSample *output, const FFTSample *input);
-attribute_deprecated
+ff_attribute_deprecated
void av_mdct_end(FFTContext *s);
/* Real Discrete Fourier Transform */
@@ -104,11 +104,11 @@ typedef struct RDFTContext RDFTContext;
*
* @deprecated use av_tx_init from libavutil/tx.h with a type of
AV_TX_FLOAT_RDFT
*/
-attribute_deprecated
+ff_attribute_deprecated
RDFTContext *av_rdft_init(int nbits, enum RDFTransformType trans);
-attribute_deprecated
+ff_attribute_deprecated
void av_rdft_calc(RDFTContext *s, FFTSample *data);
-attribute_deprecated
+ff_attribute_depreca
Re: [FFmpeg-devel] [PATCH] af_tempo.c: fix checking of samples and zero frame counts
On 3/8/24 4:34 AM, Rajiv Harlalka wrote:
Check for zeros equal to the total samples early, because in case the
check is true we would already be leaving the first few frames out.
Signed-off-by: Rajiv Harlalka
#10692
---
libavfilter/af_atempo.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
index 4621b67b03..8f31c5beaf 100644
--- a/libavfilter/af_atempo.c
+++ b/libavfilter/af_atempo.c
@@ -531,21 +531,20 @@ static int yae_load_frag(ATempoContext *atempo,
dst = frag->data;
start = atempo->position[0] - atempo->size;
- zeros = 0;
+ // what we don't have we substitute with zeros:
+ zeros = frag->position[0] < start ? FFMIN(start -
frag->position[0], (int64_t)nsamples) : 0;
+
+ if (zeros == nsamples) {
+ return 0;
+ }
if (frag->position[0] < start) {
- // what we don't have we substitute with zeros:
- zeros = FFMIN(start - frag->position[0], (int64_t)nsamples);
av_assert0(zeros != nsamples);
memset(dst, 0, zeros * atempo->stride);
dst += zeros * atempo->stride;
}
- if (zeros == nsamples) {
- return 0;
- }
-
// get the remaining data from the ring buffer:
na = (atempo->head < atempo->tail ?
atempo->tail - atempo->head :
Just a quick note to bring attention to a code patch I submitted
recently. It fixes bug #10692 from the bug tracker on the
libavfilter/av_atempo filter. A review would be greatly appreciated.
Thanks,
Rajiv
___
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] lavu/attributes: add ff_ prefix to attribute_deprecated
Anton Khirnov:
> Otherwise it might conflict with caller-defined identifiers.
>
> ff because it is not supposed to be used by external callers.
> ---
This is public, so it should be av_attribute_deprecated.
For the same reason it is actually an API break to no longer provide the
un-prefixed version.
Is this just a general precaution or did you run into an actual conflict?
> doc/developer.texi | 2 +-
> doc/print_options.c| 4 ++--
> libavcodec/avcodec.h | 4 ++--
> libavcodec/avfft.h | 30 +-
> libavcodec/packet.h| 4 ++--
> libavcodec/vdpau.h | 8 +++
> libavfilter/avfilter.h | 4 ++--
> libavformat/avformat.h | 12 +--
> libavutil/attributes.h | 12 ---
> libavutil/frame.h | 12 +--
> libavutil/hdr_dynamic_vivid_metadata.h | 12 +--
> libavutil/version.h| 1 +
> 12 files changed, 56 insertions(+), 49 deletions(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index c86bb5820c..141139df8c 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -522,7 +522,7 @@ removing the API - this is described in @ref{Major
> version bumps}.
>
> To deprecate an API you should signal to our users that they should stop
> using
> it. E.g. if you intend to remove struct members or functions, you should mark
> -them with @code{attribute_deprecated}. When this cannot be done, it may be
> +them with @code{ff_attribute_deprecated}. When this cannot be done, it may be
> possible to detect the use of the deprecated API at runtime and print a
> warning
> (though take care not to print it too often). You should also document the
> deprecation (and the replacement, if applicable) in the relevant Doxygen
> diff --git a/doc/print_options.c b/doc/print_options.c
> index fd1cf10dc1..89df2928b8 100644
> --- a/doc/print_options.c
> +++ b/doc/print_options.c
> @@ -35,8 +35,8 @@
> #include "libavutil/opt.h"
>
> /* Forcibly turn off deprecation warnings, which just add noise here. */
> -#undef attribute_deprecated
> -#define attribute_deprecated
> +#undef ff_attribute_deprecated
> +#define ff_attribute_deprecated
>
> #include "libavcodec/options_table.h"
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 21fc74707f..0c1c4eec41 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -572,7 +572,7 @@ typedef struct AVCodecContext {
> * - encoding: Set AVCodecContext.framerate instead
> *
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> int ticks_per_frame;
> #endif
>
> @@ -2370,7 +2370,7 @@ int avcodec_open2(AVCodecContext *avctx, const AVCodec
> *codec, AVDictionary **op
> * multiple times is not supported anymore -- use multiple codec contexts
> * instead.
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> int avcodec_close(AVCodecContext *avctx);
> #endif
>
> diff --git a/libavcodec/avfft.h b/libavcodec/avfft.h
> index e3a0da1eb9..1cf1cd6df1 100644
> --- a/libavcodec/avfft.h
> +++ b/libavcodec/avfft.h
> @@ -50,14 +50,14 @@ typedef struct FFTContext FFTContext;
> * @param inverse if 0 perform the forward transform, if 1 perform
> the inverse
> * @deprecated use av_tx_init from libavutil/tx.h with a type of
> AV_TX_FLOAT_FFT
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> FFTContext *av_fft_init(int nbits, int inverse);
>
> /**
> * Do the permutation needed BEFORE calling ff_fft_calc().
> * @deprecated without replacement
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_fft_permute(FFTContext *s, FFTComplex *z);
>
> /**
> @@ -65,25 +65,25 @@ void av_fft_permute(FFTContext *s, FFTComplex *z);
> * input data must be permuted before. No 1.0/sqrt(n) normalization is done.
> * @deprecated use the av_tx_fn value returned by av_tx_init, which also
> does permutation
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_fft_calc(FFTContext *s, FFTComplex *z);
>
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_fft_end(FFTContext *s);
>
> /**
> * @deprecated use av_tx_init from libavutil/tx.h with a type of
> AV_TX_FLOAT_MDCT,
> * with a flag of AV_TX_FULL_IMDCT for a replacement to av_imdct_calc.
> */
> -attribute_deprecated
> +ff_attribute_deprecated
> FFTContext *av_mdct_init(int nbits, int inverse, double scale);
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_imdct_calc(FFTContext *s, FFTSample *output, const FFTSample *input);
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_imdct_half(FFTContext *s, FFTSample *output, const FFTSample *input);
> -attribute_deprecated
> +ff_attribute_deprecated
> void av_mdct_calc(FFTContext *s, FFTSample *output, const FFTSample *input);
> -attribute_deprecated
> +ff_attribute_d
Re: [FFmpeg-devel] [PATCH] lavu/attributes: add ff_ prefix to attribute_deprecated
Quoting Andreas Rheinhardt (2024-03-12 09:56:46) > Anton Khirnov: > > Otherwise it might conflict with caller-defined identifiers. > > > > ff because it is not supposed to be used by external callers. > > --- > > This is public, so it should be av_attribute_deprecated. As the commit message says, this is not supposed to be used by external callers. Or do you see any reason why it should be public? > For the same reason it is actually an API break to no longer provide the > un-prefixed version. I am still providing the unprefixed version under a deprecation guard. > Is this just a general precaution or did you run into an actual conflict? The former. -- 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] lavc/vvc: AVERROR_PATCHWELCOME for subpictures
On 12/03/2024 03:33, Wang, Fei W wrote: > On Mon, 2024-03-11 at 21:57 -0300, James Almer wrote: >> On 3/11/2024 9:49 PM, Michael Niedermayer wrote: >>> On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote: VVC's subpictures feature is not yet implemented in the native decoder. Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream using the feature. Fixes crashes when trying to decode bitstreams which use the feature. Signed-off-by: Frank Plowman --- libavcodec/vvc/vvc_ps.c | 15 +++ 1 file changed, 15 insertions(+) >>> >>> This breaks fate-vvc-conformance-SUBPIC_A_3 >>> >>> make fate-vvc-conformance-SUBPIC_A_3 >>> TESTvvc-conformance-SUBPIC_A_3 >>> --- ./tests/ref/fate/vvc-conformance-SUBPIC_A_3 2024-03-05 >>> 02:37:36.235300141 +0100 >>> +++ tests/data/fate/vvc-conformance-SUBPIC_A_3 2024-03-12 >>> 01:47:27.301593567 +0100 >>> @@ -1,9 +0,0 @@ >>> -#tb 0: 1/25 >>> -#media_type 0: video >>> -#codec_id 0: rawvideo >>> -#dimensions 0: 1920x1080 >>> -#sar 0: 0/1 >>> -0, 0, 0,1, 6220800, 0xa419cfb6 >>> -0, 1, 1,1, 6220800, 0xa419cfb6 >>> -0, 2, 2,1, 6220800, 0xa419cfb6 >>> -0, 3, 3,1, 6220800, 0xa419cfb6 >>> Test vvc-conformance-SUBPIC_A_3 failed. Look at >>> tests/data/fate/vvc-conformance-SUBPIC_A_3.err for details. >>> tests/Makefile:318: recipe for target 'fate-vvc-conformance- >>> SUBPIC_A_3' failed >>> make: *** [fate-vvc-conformance-SUBPIC_A_3] Error 69 >>> >>> thx >> >> The sample appears to decode fine and doesn't crash, although all >> four >> frames are exactly the same (I don't know is that's intended). > > The result is correct. Assume native decode can handle subpic, at least > a part of the feature. > >> Maybe the crashes can be fixed in some other form? And abort only if >> FF_COMPLIANCE_STRICT is requested. > > Previous I made a patch to fix the crash in setup ps, but still get > error in decoding slice, it's better to return AVERROR_PATCHWELCOME > only in case of pps_single_slice_per_subpic_flag. > > https://github.com/intel-media-ci/ffmpeg/pull/723 > > Thanks > Fei Hi, Thanks all for your reviews. Yes, the feature is most problematic if pps_single_slice_per_subpic_flag is 1. This is because there is some unimplemented logic in the parameter set parser in this case which leads to some out-of-bounds accesses. Subpictures will also fail to decode bitexact if sps_independent_subpics is 1, although in practice the distortion this introduces is fairly subtle. I think we are able to decode other subpicture bitstreams bitexact. SUBPIC_A_HUAWEI_3 falls into this last category. I posted a patch, like yours Fei, which errors only the most problematic pps_single_slice_per_subpic_flag bitstreams some time ago: https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240201140055.63805-1-p...@frankplowman.com/ and the feedback I received there was to make this patch. I have also implemented the logic needed for pps_single_slice_per_subpic_flag here: https://github.com/ffvvc/FFmpeg/pull/191. I would be happy to make a v2 of the pps_single_slice_per_subpic_flag patch which moves where the error is being returned, or to put the GitHub PR on the ML if people would rather one of those two alternatives. Thanks again, -- Frank ___ 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] lavu/attributes: add ff_ prefix to attribute_deprecated
Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-12 09:56:46) >> Anton Khirnov: >>> Otherwise it might conflict with caller-defined identifiers. >>> >>> ff because it is not supposed to be used by external callers. >>> --- >> >> This is public, so it should be av_attribute_deprecated. > > As the commit message says, this is not supposed to be used by external > callers. Or do you see any reason why it should be public? > It is public given that it is declared in a public header. That is what matters. Furthermore, we have used the FF_ and AV_ prefixes for public macros and the av_ prefix for public symbols, but IIRC we do not use the ff_ prefix for public symbols at all, therefore I'd like us not to reserve another namespace. >> For the same reason it is actually an API break to no longer provide the >> un-prefixed version. > > I am still providing the unprefixed version under a deprecation guard. > I overlooked that. >> Is this just a general precaution or did you run into an actual conflict? > > The former. > ___ 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] Relative paths vs. filenames in #includes for project files.
Allan Cady via ffmpeg-devel: > To test the patch I've been working on, I wrote a small standalone C program, > which I had saved in the project root. The file I'm patching is > libavutil/timestamp.h. At first I had duplicated a bunch of definitions out > of other include files (e.g. struct AVRational, in libavutil/rational.h) so I > could run my test program in isolation, but then I decided to see if I could > make it work by including the project headers, especially by including > libavutil/timestamp.h. > > But when I tried to compile and run it that way (I'm using Visual Studio Code > with the Code Runner Extension), I got a bunch of errors that it couldn't > find several files that timestamp.h depends on. I eventually figured out this > was because some of the #includes in various files in libavutil are like this: > > #include "avutil.h" > > and others are like this: > > #include "libavutil/avconfig.h" > > In both of those cases, both the including and included files are in > libavutil. > > I changed the #includes in two files, by removing the "libavutil/", and then > my program compiled. I also tested making the whole project, and it still > compiled and ran fine as well. > > So my question is, would it make sense to remove the path from as many of > those #includes as possible, so they are filename-only? Given my limited > experience, it seems like it might not be a problem, but I don't understand > fully how the project manages source dependencies. > > Just thought I'd toss this out for comment. > With an out-of-tree build, there are two libavutil directories: The one containing the source files (.c and .h) and the one for the compiled object files. The latter also contains avconfig.h, because that depends upon the specific configuration and is therefore also not part of the FFmpeg repo. With an in-tree build, there is only one libavutil directory and avconfig.h would be reachable for the headers in libavutil/*.h via a simple '#include "avconfig.h"', but that is not the only supported configuration. It is expected that the parent directory of the lib* source directories as well as the parent directory of the lib* build directories is part of the directories where the compiler searches for ""-includes. Just look at the compilation command for some .o file via "make libavutil/channel_layout.o V=1". It contains "-I. -Isrc/" for out-of-tree builds. - 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".
Re: [FFmpeg-devel] [PATCH] lavu/attributes: add ff_ prefix to attribute_deprecated
Quoting Andreas Rheinhardt (2024-03-12 10:21:52) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2024-03-12 09:56:46) > >> Anton Khirnov: > >>> Otherwise it might conflict with caller-defined identifiers. > >>> > >>> ff because it is not supposed to be used by external callers. > >>> --- > >> > >> This is public, so it should be av_attribute_deprecated. > > > > As the commit message says, this is not supposed to be used by external > > callers. Or do you see any reason why it should be public? > > > > It is public given that it is declared in a public header. That is what > matters. I agree that it is (implicitly) public now, but the question is whether it should be. IMO it should not. Do you disagree? > Furthermore, we have used the FF_ and AV_ prefixes for public macros and > the av_ prefix for public symbols, but IIRC we do not use the ff_ prefix > for public symbols at all, therefore I'd like us not to reserve another > namespace. We do reserve the ff namespace for private identifiers that need to be exposed, e.g. in public headers or when linking statically. -- 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] doc/examples/qsv_decode.c: remove unused config.h header file
On date Monday 2024-03-11 13:41:43 +, hung kuishing wrote: > > 在 2024年3月10日，21:55，Stefano Sabatini 写道： > > > > On date Saturday 2024-03-09 02:17:19 +, hung kuishing wrote: > >> > >> Signed-off-by: clarkh > >> mailto:hungkuish...@outlook.com>> > >> --- > >> doc/examples/qsv_decode.c | 2 -- > >> 1 file changed, 2 deletions(-) > >> > >> diff --git a/doc/examples/qsv_decode.c b/doc/examples/qsv_decode.c > >> index cc2662d5bd..901eac3b27 100644 > >> --- a/doc/examples/qsv_decode.c > >> +++ b/doc/examples/qsv_decode.c > >> @@ -28,8 +28,6 @@ > >> * GPU video surfaces, write the decoded frames to an output file. > >> */ > >> > >> -#include "config.h" > >> - > >> #include > >> > >> #include "libavformat/avformat.h" > >> -- > >> 2.34.1 > > > > Looks good but it fails with: > > git am --abort; git am patches/fix-doc-qsvdec.patch > > Applying: doc/examples/qsv_decode.c: remove unused config.h header file > > error: corrupt patch at line 15 > > > > Can you try to generate the patch (git format-patch) and attach it to > > the thread? > > > > Or I'll just apply the diff manually. > Ok, please apply the diff manually, thanks will push soon, 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 3/3] avformat/dvdvideodec: add menu demuxing support
On date Saturday 2024-03-09 12:27:52 -0600, Marth64 wrote:
> Signed-off-by: Marth64
> ---
> doc/demuxers.texi | 43 +-
> libavformat/dvdvideodec.c | 314 --
> 2 files changed, 339 insertions(+), 18 deletions(-)
Will push soon with the other patch, thanks.
BTW this is causing this warning:
libavformat/dvdvideodec.c: In function ‘dvdvideo_menu_next_ps_block’:
libavformat/dvdvideodec.c:426:83: warning: format ‘%d’ expects argument of type
‘int’, but argument 5 has type ‘ssize_t’ {aka ‘long int’} [-Wformat=]
426 | av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%d\n",
|
~^
|
|
|
int
|
%ld
427 | state->sector_offset, blocks_read);
| ~~~
| |
| ssize_t {aka long
int}
[...]
___
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/aea: Add aea muxer
On date Sunday 2024-03-10 16:10:15 +0100, Stefano Sabatini wrote:
> On date Sunday 2024-03-10 14:20:12 +, ffmpeg-devel Mailing List wrote:
> > Great, thank you very much!
> > I'm attaching the (hopefully) final version of the patch.
> >
>
> > MD studio was a piece of software created by a company called "EDL",
> > which in combination with alternative firmware for the Sony MDH-10
> > MiniDisc recorder
> > (https://www.minidisc.wiki/equipment/sony/misc/mdh-10) let people
> > download raw ATRAC1 audio from their MiniDiscs onto computers, and
> > (probably) put this audio back on their discs later. Nowadays it's
> > used by software like Web Minidisc Pro (which I maintain) to store
> > ATRAC1 audio, as it (until recently) was the only way to store
> > ATRAC1 so that it would be picked up by VLC. Now we have matroska
> > support for ATRAC1, but I wanted to write a muxer for AEA before I
> > phase it out from new pieces of software, so that the people who
> > would like to use AEA instead of matroska have a way to go back to
> > it.
>
> Thanks, probably part of this information could go to the doc to
> provide some context (can be done as a separate patch), as this kind
> of info is very difficult to retrieve otherwise (and one of the goals
> of FFmpeg is digital preservation).
>
> > From e67d2df52c65528fbbfe8d5268661c88a7ad225e Mon Sep 17 00:00:00 2001
> > From: asivery
> > Date: Fri, 8 Mar 2024 14:45:02 +0100
> > Subject: [PATCH] avformat/aea: Add aea muxer
> >
> > Signed-off-by: asivery
> > ---
> > Changelog | 1 +
> > doc/muxers.texi | 10 +++
> > libavformat/Makefile| 3 +-
> > libavformat/{aea.c => aeadec.c} | 0
> > libavformat/aeaenc.c| 115
> > libavformat/allformats.c| 1 +
> > 6 files changed, 129 insertions(+), 1 deletion(-)
> > rename libavformat/{aea.c => aeadec.c} (100%)
> > create mode 100644 libavformat/aeaenc.c
>
> Patch looks good to me, waiting for more feedback by Andreas.
Will apply it soon, 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 3/3] doc/muxers/fifo: review documentation
On date Monday 2024-03-11 11:32:29 -0500, Marth64 wrote: > LGTM from readability perspective. Nice catch on the command missing slash. Thanks, applied. ___ 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/3] lavf/fifo: sort options by name
On date Monday 2024-03-11 11:31:15 -0500, Marth64 wrote: > LGTM. Options before are the same as after change. Applied. ___ 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] lavu/attributes: add ff_ prefix to attribute_deprecated
Anton Khirnov: > Quoting Andreas Rheinhardt (2024-03-12 10:21:52) >> Anton Khirnov: >>> Quoting Andreas Rheinhardt (2024-03-12 09:56:46) Anton Khirnov: > Otherwise it might conflict with caller-defined identifiers. > > ff because it is not supposed to be used by external callers. > --- This is public, so it should be av_attribute_deprecated. >>> >>> As the commit message says, this is not supposed to be used by external >>> callers. Or do you see any reason why it should be public? >>> >> >> It is public given that it is declared in a public header. That is what >> matters. > > I agree that it is (implicitly) public now, but the question is whether > it should be. IMO it should not. Do you disagree? > It needs to be available in a public header given that deprecations are supposed to convey information to the public. If you are asking whether we should add a note like the one for the FF_API_ defines: I don't have formed an opinion on that yet. >> Furthermore, we have used the FF_ and AV_ prefixes for public macros and >> the av_ prefix for public symbols, but IIRC we do not use the ff_ prefix >> for public symbols at all, therefore I'd like us not to reserve another >> namespace. > > We do reserve the ff namespace for private identifiers that need to be > exposed, e.g. in public headers or when linking statically. > We reserve the FF_ namespace in public headers, not the ff_ namespace. If I am not mistaken we never use the latter namespace in public for stuff without linkage (i.e. a project could use the ff_ namespace for macros/enums without conflicting with FFmpeg). - 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/muxers: add ffmetadata
---
doc/metadata.texi | 1 +
doc/muxers.texi | 16
2 files changed, 17 insertions(+)
diff --git a/doc/metadata.texi b/doc/metadata.texi
index be91059a98..e081da7735 100644
--- a/doc/metadata.texi
+++ b/doc/metadata.texi
@@ -1,3 +1,4 @@
+@anchor{metadata}
@chapter Metadata
@c man begin METADATA
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a697e4b153..0aaef2b520 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1429,6 +1429,22 @@ Use @command{ffmpeg} to convert the input:
ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r 29.97 -ac 2 -ar 48000 -y
out.dv
@end example
+@section ffmetadata
+FFmpeg metadata muxer.
+
+This muxer writes the streams metadata in the @samp{ffmetadata}
+format.
+
+See @ref{metadata,,the Metadata chapter,ffmpeg-formats} for
+information about the format.
+
+@subsection Example
+Copy an input file and insert metadata information from an
@file{metadata.ffmeta} file in
+@samp{ffmetadata} format:
+@example
+ffmpeg -i INPUT -i metadata.ffmeta -map_metadata 1 -codec copy OUTPUT
+@end example
+
@anchor{fifo}
@section fifo
FIFO (First-In First-Out) muxer.
--
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] lavf/fifo_test: sort options by name
---
libavformat/fifo_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
index 3861c4aee4..84b762db5f 100644
--- a/libavformat/fifo_test.c
+++ b/libavformat/fifo_test.c
@@ -122,12 +122,12 @@ static void failing_deinit(AVFormatContext *avf)
}
#define OFFSET(x) offsetof(FailingMuxerContext, x)
static const AVOption options[] = {
+{"print_deinit_summary", "print summary when deinitializing muxer",
OFFSET(print_deinit_summary),
+ AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{"write_header_ret", "write_header() return value",
OFFSET(write_header_ret),
AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
{"write_trailer_ret", "write_trailer() return value",
OFFSET(write_trailer_ret),
AV_OPT_TYPE_INT, {.i64 = 0}, INT_MIN, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
-{"print_deinit_summary", "print summary when deinitializing muxer",
OFFSET(print_deinit_summary),
- AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{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] lavf/fifo_test: use FifoTest in place of Failing
Use a more consistent and sensible prefix for the muxer structs and functions.
---
libavformat/fifo_test.c | 45 -
1 file changed, 22 insertions(+), 23 deletions(-)
diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
index 84b762db5f..903f4bc34b 100644
--- a/libavformat/fifo_test.c
+++ b/libavformat/fifo_test.c
@@ -1,5 +1,5 @@
/*
- * FIFO test pseudo-muxer
+ * FIFO pseudo-muxer test
* Copyright (c) 2016 Jan Sebechlebsky
*
* This file is part of FFmpeg.
@@ -38,14 +38,13 @@
/* This is structure of data sent in packets to
* failing muxer */
-typedef struct FailingMuxerPacketData {
+typedef struct FifoTestMuxerPacketData {
int ret; /* return value of write_packet call*/
int recover_after; /* set ret to zero after this number of recovery
attempts */
unsigned sleep_time; /* sleep for this long in write_packet to simulate
long I/O operation */
-} FailingMuxerPacketData;
+} FifoTestMuxerPacketData;
-
-typedef struct FailingMuxerContext {
+typedef struct FifoTestMuxerContext {
AVClass *class;
int write_header_ret;
int write_trailer_ret;
@@ -55,22 +54,22 @@ typedef struct FailingMuxerContext {
int flush_count;
int pts_written[MAX_TST_PACKETS];
int pts_written_nr;
-} FailingMuxerContext;
+} FifoTestMuxerContext;
-static int failing_write_header(AVFormatContext *avf)
+static int fifo_test_write_header(AVFormatContext *avf)
{
-FailingMuxerContext *ctx = avf->priv_data;
+FifoTestMuxerContext *ctx = avf->priv_data;
return ctx->write_header_ret;
}
-static int failing_write_packet(AVFormatContext *avf, AVPacket *pkt)
+static int fifo_test_write_packet(AVFormatContext *avf, AVPacket *pkt)
{
-FailingMuxerContext *ctx = avf->priv_data;
+FifoTestMuxerContext *ctx = avf->priv_data;
int ret = 0;
if (!pkt) {
ctx->flush_count++;
} else {
-FailingMuxerPacketData *data = (FailingMuxerPacketData*) pkt->data;
+FifoTestMuxerPacketData *data = (FifoTestMuxerPacketData*) pkt->data;
if (!data->recover_after) {
data->ret = 0;
@@ -98,16 +97,16 @@ static int failing_write_packet(AVFormatContext *avf,
AVPacket *pkt)
return ret;
}
-static int failing_write_trailer(AVFormatContext *avf)
+static int fifo_test_write_trailer(AVFormatContext *avf)
{
-FailingMuxerContext *ctx = avf->priv_data;
+FifoTestMuxerContext *ctx = avf->priv_data;
return ctx->write_trailer_ret;
}
-static void failing_deinit(AVFormatContext *avf)
+static void fifo_test_deinit(AVFormatContext *avf)
{
int i;
-FailingMuxerContext *ctx = avf->priv_data;
+FifoTestMuxerContext *ctx = avf->priv_data;
if (!ctx->print_deinit_summary)
return;
@@ -120,7 +119,7 @@ static void failing_deinit(AVFormatContext *avf)
}
printf("\n");
}
-#define OFFSET(x) offsetof(FailingMuxerContext, x)
+#define OFFSET(x) offsetof(FifoTestMuxerContext, x)
static const AVOption options[] = {
{"print_deinit_summary", "print summary when deinitializing muxer",
OFFSET(print_deinit_summary),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
@@ -131,7 +130,7 @@ static const AVOption options[] = {
{NULL}
};
-static const AVClass failing_muxer_class = {
+static const AVClass fifo_test_muxer_class = {
.class_name = "Fifo test muxer",
.item_name = av_default_item_name,
.option = options,
@@ -141,12 +140,12 @@ static const AVClass failing_muxer_class = {
const FFOutputFormat ff_fifo_test_muxer = {
.p.name = "fifo_test",
.p.long_name= NULL_IF_CONFIG_SMALL("Fifo test muxer"),
-.priv_data_size = sizeof(FailingMuxerContext),
-.write_header = failing_write_header,
-.write_packet = failing_write_packet,
-.write_trailer = failing_write_trailer,
-.deinit = failing_deinit,
-.p.priv_class = &failing_muxer_class,
+.priv_data_size = sizeof(FifoTestMuxerContext),
+.write_header = fifo_test_write_header,
+.write_packet = fifo_test_write_packet,
+.write_trailer = fifo_test_write_trailer,
+.deinit = fifo_test_deinit,
+.p.priv_class = &fifo_test_muxer_class,
#if FF_API_ALLOW_FLUSH
.p.flags= AVFMT_NOFILE | AVFMT_ALLOW_FLUSH,
#else
--
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] doc/muxers: add fifo_test
---
doc/muxers.texi | 30 ++
1 file changed, 30 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 0aaef2b520..ccbb741992 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1556,6 +1556,36 @@ ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo
-fifo_format flv \
-map 0:v -map 0:a rtmp://example.com/live/stream_name
@end example
+@anchor{fifo_test}
+@section fifo_test
+@ref{fifo} muxer test muxer.
+
+This is a testing muxer, it is supposed to be used only to test the
+@ref{fifo} muxer.
+
+@subsection Options
+@table @option
+@item print_deinit_summary @var{bool}
+print summary when deinitializing muxer, default is @code{true}
+
+@item write_header_ret @var{int}
+set @code{write_header()} return value
+
+@item write_trailer_ret @var{int}
+set @code{write_trailer()} return value
+@end table
+
+@subsection Example
+
+Use @command{ffmpeg} to write to a file using the @samp{fifo} muxer
+using the internal @samp{fifo_test} muxer, simulate a write header
+error using the @option{write_header_ret} option:
+@example
+ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo -fifo_format fifo_test
-format_opts write_header_ret=-22 \
+ -map 0:v -map 0:a \
+ -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 out.test
+@end example
+
@section flv
Adobe Flash Video Format muxer.
--
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 v3 1/6] avcodec/mpeg12dec: extract only one type of CC substream
On date Tuesday 2024-03-12 01:00:00 -0500, Marth64 wrote:
> In MPEG-2 user data, there can be different types of Closed Captions
> formats embedded (A53, SCTE-20, or DVD). The current behavior of the
> CC extraction code in the MPEG-2 decoder is to not be aware of
> multiple formats if multiple exist, therefore allowing one format
> to overwrite the other during the extraction process since the CC
> extraction shares one output buffer for the normalized bytes.
>
> This causes sources that have two CC formats to produce flawed output.
> There exist real-world samples which contain both A53 and SCTE-20 captions
> in the same MPEG-2 stream, and that manifest this problem. Example of symptom:
> THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
>
> The solution is to pick only the first CC substream observed with valid bytes,
> and ignore the other types. Additionally, provide an option for users
> to manually "force" a type in the event that this matters for a particular
> source.
>
> Signed-off-by: Marth64
> ---
> libavcodec/mpeg12dec.c | 67 --
> 1 file changed, 64 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 3a2f17e508..8961a290a3 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -62,6 +62,16 @@
>
> #define A53_MAX_CC_COUNT 2000
>
> +enum Mpeg2ClosedCaptionsFormat {
> +CC_FORMAT_AUTO,
> +CC_FORMAT_A53_PART4,
> +CC_FORMAT_SCTE20,
> +CC_FORMAT_DVD
> +};
> +static const char mpeg2_cc_format_labels[4][12] = {
nit: this might be
static const char *mpeg2_cc_format_labels[4] = {
to avoid unnecessary constraints on the string length, or you might
pass the CC name in the function directly to avoid to maintain the
array (as it is not shared at the moment)
> +"Unknown", "A/53 Part 4", "SCTE-20", "DVD"
> +};
> +
[...]
LGTM otherwise.
___
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/muxers: add ffmetadata
On 2024-03-12 04:25 pm, Stefano Sabatini wrote:
---
doc/metadata.texi | 1 +
doc/muxers.texi | 16
2 files changed, 17 insertions(+)
diff --git a/doc/metadata.texi b/doc/metadata.texi
index be91059a98..e081da7735 100644
--- a/doc/metadata.texi
+++ b/doc/metadata.texi
@@ -1,3 +1,4 @@
+@anchor{metadata}
@chapter Metadata
@c man begin METADATA
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a697e4b153..0aaef2b520 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1429,6 +1429,22 @@ Use @command{ffmpeg} to convert the input:
ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r 29.97 -ac 2 -ar 48000 -y
out.dv
@end example
+@section ffmetadata
+FFmpeg metadata muxer.
+
+This muxer writes the streams metadata in the @samp{ffmetadata}
+format.
+
+See @ref{metadata,,the Metadata chapter,ffmpeg-formats} for
+information about the format.
+
+@subsection Example
+Copy an input file and insert metadata information from an
@file{metadata.ffmeta} file in
+@samp{ffmetadata} format:
+@example
+ffmpeg -i INPUT -i metadata.ffmeta -map_metadata 1 -codec copy OUTPUT
+@end example
+
The above example is for the demuxer only. Better to include an initial
step showing export.
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] avformat/aea: Add aea muxer
Thank you Stefano Sabatini and Andreas Rheinhardt - you guys have the patience
of saints.
On Tuesday, March 12th, 2024 at 11:27 AM, Stefano Sabatini
wrote:
> On date Sunday 2024-03-10 16:10:15 +0100, Stefano Sabatini wrote:
>
> > On date Sunday 2024-03-10 14:20:12 +, ffmpeg-devel Mailing List wrote:
> >
> > > Great, thank you very much!
> > > I'm attaching the (hopefully) final version of the patch.
> >
> > > MD studio was a piece of software created by a company called "EDL",
> > > which in combination with alternative firmware for the Sony MDH-10
> > > MiniDisc recorder
> > > (https://www.minidisc.wiki/equipment/sony/misc/mdh-10) let people
> > > download raw ATRAC1 audio from their MiniDiscs onto computers, and
> > > (probably) put this audio back on their discs later. Nowadays it's
> > > used by software like Web Minidisc Pro (which I maintain) to store
> > > ATRAC1 audio, as it (until recently) was the only way to store
> > > ATRAC1 so that it would be picked up by VLC. Now we have matroska
> > > support for ATRAC1, but I wanted to write a muxer for AEA before I
> > > phase it out from new pieces of software, so that the people who
> > > would like to use AEA instead of matroska have a way to go back to
> > > it.
> >
> > Thanks, probably part of this information could go to the doc to
> > provide some context (can be done as a separate patch), as this kind
> > of info is very difficult to retrieve otherwise (and one of the goals
> > of FFmpeg is digital preservation).
> >
> > > From e67d2df52c65528fbbfe8d5268661c88a7ad225e Mon Sep 17 00:00:00 2001
> > > From: asivery asiv...@protonmail.com
> > > Date: Fri, 8 Mar 2024 14:45:02 +0100
> > > Subject: [PATCH] avformat/aea: Add aea muxer
> > >
> > > Signed-off-by: asivery asiv...@protonmail.com
> > > ---
> > > Changelog | 1 +
> > > doc/muxers.texi | 10 +++
> > > libavformat/Makefile | 3 +-
> > > libavformat/{aea.c => aeadec.c} | 0
> > > libavformat/aeaenc.c | 115
> > > libavformat/allformats.c | 1 +
> > > 6 files changed, 129 insertions(+), 1 deletion(-)
> > > rename libavformat/{aea.c => aeadec.c} (100%)
> > > create mode 100644 libavformat/aeaenc.c
> >
> > Patch looks good to me, waiting for more feedback by Andreas.
>
>
> Will apply it soon, 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 v3 5/6] avformat/rcwtdec: add RCWT Closed Captions demuxer
Marth64:
> Raw Captions With Time (RCWT) is a format native to ccextractor, a commonly
> used open source tool for processing 608/708 Closed Captions (CC) sources.
> RCWT can be used to archive the original CC bitstream. The muxer was added
> in January 2024. In this commit, add the demuxer.
>
> One can now demux RCWT files for rendering in ccaption_dec or interoperate
> with ccextractor (which produces RCWT). Using the muxer/demuxer combination,
> the CC bits can be kept for further processing or rendering with either tool.
> This can be an effective approach to backup original CC presentations.
>
> Prior to this, the next best solution was FFmpeg's SCC muxer, but SCC itself
> is not compatible with ccextractor (which is a de facto OSS CC processing
> tool)
> and it is a proprietary format.
>
> Tests will follow.
>
> Signed-off-by: Marth64
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/rcwtdec.c| 158 +++
> 3 files changed, 160 insertions(+)
> create mode 100644 libavformat/rcwtdec.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 8811a0ffc9..2092ca9f38 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -493,6 +493,7 @@ OBJS-$(CONFIG_QOA_DEMUXER) += qoadec.o
> OBJS-$(CONFIG_R3D_DEMUXER) += r3d.o
> OBJS-$(CONFIG_RAWVIDEO_DEMUXER) += rawvideodec.o
> OBJS-$(CONFIG_RAWVIDEO_MUXER)+= rawenc.o
> +OBJS-$(CONFIG_RCWT_DEMUXER) += rcwtdec.o subtitles.o
> OBJS-$(CONFIG_RCWT_MUXER)+= rcwtenc.o subtitles.o
> OBJS-$(CONFIG_REALTEXT_DEMUXER) += realtextdec.o subtitles.o
> OBJS-$(CONFIG_REDSPARK_DEMUXER) += redspark.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0a0e76138f..b89a49b6ec 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -391,6 +391,7 @@ extern const FFInputFormat ff_qoa_demuxer;
> extern const FFInputFormat ff_r3d_demuxer;
> extern const FFInputFormat ff_rawvideo_demuxer;
> extern const FFOutputFormat ff_rawvideo_muxer;
> +extern const FFInputFormat ff_rcwt_demuxer;
> extern const FFOutputFormat ff_rcwt_muxer;
> extern const FFInputFormat ff_realtext_demuxer;
> extern const FFInputFormat ff_redspark_demuxer;
> diff --git a/libavformat/rcwtdec.c b/libavformat/rcwtdec.c
> new file mode 100644
> index 00..f553f13366
> --- /dev/null
> +++ b/libavformat/rcwtdec.c
> @@ -0,0 +1,158 @@
> +/*
> + * RCWT (Raw Captions With Time) demuxer
> + *
> + * 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
> + */
> +
> +/*
> + * RCWT (Raw Captions With Time) is a format native to ccextractor, a
> commonly
> + * used open source tool for processing 608/708 Closed Captions (CC) sources.
> + * It can be used to archive the original, raw CC bitstream and to produce
> + * a source file for later CC processing or conversion. As a result,
> + * it also allows for interopability with ccextractor for processing CC data
> + * extracted via ffmpeg. The format is simple to parse and can be used
> + * to retain all lines and variants of CC.
> + *
> + * This demuxer implements the specification as of March 2024, which has
> + * been stable and unchanged since April 2014.
> + *
> + * A free specification of RCWT can be found here:
> + *
> @url{https://github.com/CCExtractor/ccextractor/blob/master/docs/BINARY_FILE_FORMAT.TXT}
> + */
> +
> +#include "avformat.h"
> +#include "demux.h"
> +#include "internal.h"
> +#include "subtitles.h"
> +#include "libavutil/avstring.h"
> +#include "libavutil/intreadwrite.h"
What are these two headers used for? (Didn't you add the same unused
headers to the muxer?)
> +
> +#define RCWT_CLUSTER_MAX_BLOCKS 65535
> +#define RCWT_BLOCK_SIZE 3
> +#define RCWT_HEADER_SIZE11
> +
> +typedef struct RCWTContext {
> +FFDemuxSubtitlesQueue q;
> +} RCWTContext;
> +
> +static int rcwt_read_header(AVFormatContext *avf)
> +{
> +RCWTContext *rcwt = avf->priv_data;
> +
> +AVPacket *sub = NULL;
> +AVStream *st;
> +uint8_t header[RCWT_HEADER_SIZE] = {0};
> +int nb_bytes = 0;
> +
> +
Re: [FFmpeg-devel] [PATCH v3 1/6] avcodec/mpeg12dec: extract only one type of CC substream
Stefano Sabatini:
> On date Tuesday 2024-03-12 01:00:00 -0500, Marth64 wrote:
>> In MPEG-2 user data, there can be different types of Closed Captions
>> formats embedded (A53, SCTE-20, or DVD). The current behavior of the
>> CC extraction code in the MPEG-2 decoder is to not be aware of
>> multiple formats if multiple exist, therefore allowing one format
>> to overwrite the other during the extraction process since the CC
>> extraction shares one output buffer for the normalized bytes.
>>
>> This causes sources that have two CC formats to produce flawed output.
>> There exist real-world samples which contain both A53 and SCTE-20 captions
>> in the same MPEG-2 stream, and that manifest this problem. Example of
>> symptom:
>> THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
>>
>> The solution is to pick only the first CC substream observed with valid
>> bytes,
>> and ignore the other types. Additionally, provide an option for users
>> to manually "force" a type in the event that this matters for a particular
>> source.
>>
>> Signed-off-by: Marth64
>> ---
>> libavcodec/mpeg12dec.c | 67 --
>> 1 file changed, 64 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
>> index 3a2f17e508..8961a290a3 100644
>> --- a/libavcodec/mpeg12dec.c
>> +++ b/libavcodec/mpeg12dec.c
>> @@ -62,6 +62,16 @@
>>
>> #define A53_MAX_CC_COUNT 2000
>>
>> +enum Mpeg2ClosedCaptionsFormat {
>> +CC_FORMAT_AUTO,
>> +CC_FORMAT_A53_PART4,
>> +CC_FORMAT_SCTE20,
>> +CC_FORMAT_DVD
>> +};
>
>> +static const char mpeg2_cc_format_labels[4][12] = {
>
> nit: this might be
> static const char *mpeg2_cc_format_labels[4] = {
>
This would add relocations and put this into .data.rel.ro.
> to avoid unnecessary constraints on the string length, or you might
> pass the CC name in the function directly to avoid to maintain the
> array (as it is not shared at the moment)
>
That sound like a good idea.
>> +"Unknown", "A/53 Part 4", "SCTE-20", "DVD"
>> +};
>> +
>
> [...]
>
> LGTM otherwise.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fate: fix generating references when sh=dash
Regression since 0b98f28c46a7e3e914c51debc461
Signed-off-by: Nicolas Gaullier
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 0fead78c58..9863e4f2d9 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -672,7 +672,7 @@ else
fi
echo "${test}:${sig:-$err}:$cmpo:$erro" >$repfile
-if test $err != 0 && test $gen != "no" && test "${ref#tests/data/}" == "$ref"
; then
+if test $err != 0 && test $gen != "no" && test "${ref#tests/data/}" = "$ref" ;
then
echo "GEN $ref"
cp -f "$outfile" "$ref"
err=$?
--
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] doc/fate: advise on --assert-level=2
Signed-off-by: Nicolas Gaullier
---
doc/fate.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2fa8c34c2d..17644ce65a 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,14 @@ Do not put a '~' character in the samples path to indicate a
home
directory. Because of shell nuances, this will cause FATE to fail.
@end float
+Beware that some assertions are disabled by default, so mind setting
+@option{--assert-level=} at configuration time, e.g. when seeking
+the highest possible test coverage:
+@example
+./configure --assert-level=2
+@end example
+Note that raising the assert level could have a performance impact.
+
To get the complete list of tests, run the command:
@example
make fate-list
--
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 3/3] doc/muxers: add fifo_test
Stefano Sabatini:
> ---
> doc/muxers.texi | 30 ++
> 1 file changed, 30 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 0aaef2b520..ccbb741992 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1556,6 +1556,36 @@ ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo
> -fifo_format flv \
>-map 0:v -map 0:a rtmp://example.com/live/stream_name
> @end example
>
> +@anchor{fifo_test}
> +@section fifo_test
> +@ref{fifo} muxer test muxer.
> +
> +This is a testing muxer, it is supposed to be used only to test the
> +@ref{fifo} muxer.
> +
> +@subsection Options
> +@table @option
> +@item print_deinit_summary @var{bool}
> +print summary when deinitializing muxer, default is @code{true}
> +
> +@item write_header_ret @var{int}
> +set @code{write_header()} return value
> +
> +@item write_trailer_ret @var{int}
> +set @code{write_trailer()} return value
> +@end table
> +
> +@subsection Example
> +
> +Use @command{ffmpeg} to write to a file using the @samp{fifo} muxer
> +using the internal @samp{fifo_test} muxer, simulate a write header
> +error using the @option{write_header_ret} option:
> +@example
> +ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo -fifo_format fifo_test
> -format_opts write_header_ret=-22 \
> + -map 0:v -map 0:a \
> + -drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 out.test
> +@end example
> +
> @section flv
>
> Adobe Flash Video Format muxer.
I do not think that this muxer should be publically documented. In fact,
I think it would be better if this muxer would only exist inside the
fifo_muxer test and if it were not included in a normal libavformat at all.
- 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".
Re: [FFmpeg-devel] [PATCH v2 2/2] lavc/vvc_ps: Correct NoOutputBeforeRecoveryFlag of IDR
On Mon, Mar 11, 2024 at 9:58 AM wrote:
> From: Fei Wang
>
> The NoOutputBeforeRecoveryFlag of an IDR frame should be set to 1 as
> spec says in 8.1.1.
>
Pushed.
Thank you, Fei.
>
> Signed-off-by: Fei Wang
> ---
> libavcodec/vvc/vvc_ps.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
> index e6e46d2039..7972803da6 100644
> --- a/libavcodec/vvc/vvc_ps.c
> +++ b/libavcodec/vvc/vvc_ps.c
> @@ -742,7 +742,7 @@ static int decode_frame_ps(VVCFrameParamSets *fps,
> const VVCParamSets *ps,
> static void decode_recovery_flag(VVCContext *s)
> {
> if (IS_IDR(s))
> -s->no_output_before_recovery_flag = 0;
> +s->no_output_before_recovery_flag = 1;
> else if (IS_CRA(s) || IS_GDR(s))
> s->no_output_before_recovery_flag = s->last_eos;
> }
> --
> 2.25.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel 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] lavc/vvc: AVERROR_PATCHWELCOME for subpictures
On Tue, Mar 12, 2024 at 5:09 PM Frank Plowman wrote: > On 12/03/2024 03:33, Wang, Fei W wrote: > > On Mon, 2024-03-11 at 21:57 -0300, James Almer wrote: > >> On 3/11/2024 9:49 PM, Michael Niedermayer wrote: > >>> On Mon, Mar 11, 2024 at 06:53:31PM +, Frank Plowman wrote: > VVC's subpictures feature is not yet implemented in the native > decoder. > Throw an AVERROR_PATCHWELCOME when trying to decode a bitstream > using > the feature. Fixes crashes when trying to decode bitstreams > which > use the feature. > > Signed-off-by: Frank Plowman > --- > libavcodec/vvc/vvc_ps.c | 15 +++ > 1 file changed, 15 insertions(+) > >>> > >>> This breaks fate-vvc-conformance-SUBPIC_A_3 > >>> > >>> make fate-vvc-conformance-SUBPIC_A_3 > >>> TESTvvc-conformance-SUBPIC_A_3 > >>> --- ./tests/ref/fate/vvc-conformance-SUBPIC_A_3 2024-03-05 > >>> 02:37:36.235300141 +0100 > >>> +++ tests/data/fate/vvc-conformance-SUBPIC_A_3 2024-03-12 > >>> 01:47:27.301593567 +0100 > >>> @@ -1,9 +0,0 @@ > >>> -#tb 0: 1/25 > >>> -#media_type 0: video > >>> -#codec_id 0: rawvideo > >>> -#dimensions 0: 1920x1080 > >>> -#sar 0: 0/1 > >>> -0, 0, 0,1, 6220800, 0xa419cfb6 > >>> -0, 1, 1,1, 6220800, 0xa419cfb6 > >>> -0, 2, 2,1, 6220800, 0xa419cfb6 > >>> -0, 3, 3,1, 6220800, 0xa419cfb6 > >>> Test vvc-conformance-SUBPIC_A_3 failed. Look at > >>> tests/data/fate/vvc-conformance-SUBPIC_A_3.err for details. > >>> tests/Makefile:318: recipe for target 'fate-vvc-conformance- > >>> SUBPIC_A_3' failed > >>> make: *** [fate-vvc-conformance-SUBPIC_A_3] Error 69 > >>> > >>> thx > >> > >> The sample appears to decode fine and doesn't crash, although all > >> four > >> frames are exactly the same (I don't know is that's intended). > > > > The result is correct. Assume native decode can handle subpic, at least > > a part of the feature. > > > >> Maybe the crashes can be fixed in some other form? And abort only if > >> FF_COMPLIANCE_STRICT is requested. > > > > Previous I made a patch to fix the crash in setup ps, but still get > > error in decoding slice, it's better to return AVERROR_PATCHWELCOME > > only in case of pps_single_slice_per_subpic_flag. > > > > https://github.com/intel-media-ci/ffmpeg/pull/723 > > > > Thanks > > Fei > > Hi, > > Thanks all for your reviews. > > Yes, the feature is most problematic if pps_single_slice_per_subpic_flag > is 1. This is because there is some unimplemented logic in the > parameter set parser in this case which leads to some out-of-bounds > accesses. Subpictures will also fail to decode bitexact if > sps_independent_subpics is 1, although in practice the distortion this > introduces is fairly subtle. I think we are able to decode other > subpicture bitstreams bitexact. SUBPIC_A_HUAWEI_3 falls into this last > category. > > I posted a patch, like yours Fei, which errors only the most problematic > pps_single_slice_per_subpic_flag bitstreams some time ago: > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20240201140055.63805-1-p...@frankplowman.com/ > and the feedback I received there was to make this patch. I have also > implemented the logic needed for pps_single_slice_per_subpic_flag here: > https://github.com/ffvvc/FFmpeg/pull/191. I would be happy to make a v2 > of the pps_single_slice_per_subpic_flag patch which moves where the > error is being returned, or to put the GitHub PR on the ML if people > would rather one of those two alternatives. > Hi Frank and all, Thank you for the patch and review. I have a local patch for subpic, hope I can make all clips passed and send out patches in the following 1~2 weeks. > > Thanks again, > -- > Frank > ___ > 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] af_tempo.c: fix checking of samples and zero frame counts
On Tue, Mar 12, 2024, 02:52 Rajiv Harlalka
wrote:
> On 3/8/24 4:34 AM, Rajiv Harlalka wrote:
> > Check for zeros equal to the total samples early, because in case the
> > check is true we would already be leaving the first few frames out.
> >
> > Signed-off-by: Rajiv Harlalka
> > #10692
> > ---
> > libavfilter/af_atempo.c | 13 ++---
> > 1 file changed, 6 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavfilter/af_atempo.c b/libavfilter/af_atempo.c
> > index 4621b67b03..8f31c5beaf 100644
> > --- a/libavfilter/af_atempo.c
> > +++ b/libavfilter/af_atempo.c
> > @@ -531,21 +531,20 @@ static int yae_load_frag(ATempoContext *atempo,
> > dst = frag->data;
> > start = atempo->position[0] - atempo->size;
> > -zeros = 0;
> > +// what we don't have we substitute with zeros:
> > +zeros = frag->position[0] < start ? FFMIN(start -
> > frag->position[0], (int64_t)nsamples) : 0;
> > +
> > +if (zeros == nsamples) {
> > +return 0;
> > +}
> > if (frag->position[0] < start) {
> > -// what we don't have we substitute with zeros:
> > -zeros = FFMIN(start - frag->position[0], (int64_t)nsamples);
> > av_assert0(zeros != nsamples);
> > memset(dst, 0, zeros * atempo->stride);
> > dst += zeros * atempo->stride;
> > }
> > -if (zeros == nsamples) {
> > -return 0;
> > -}
> > -
> > // get the remaining data from the ring buffer:
> > na = (atempo->head < atempo->tail ?
> >atempo->tail - atempo->head :
>
> Just a quick note to bring attention to a code patch I submitted
> recently. It fixes bug #10692 from the bug tracker on the
> libavfilter/av_atempo filter. A review would be greatly appreciated.
>
> Thanks,
> Rajiv
>
> ___
> 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".
>
I should be able to test the patch tonight after work.
Thank you,
Pavel.
___
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/4] aarch64: Fix ff_hevc_put_hevc_epel_h48_8_neon_i8mm
The first 32 elements of each row were correct, while the
last 16 were scrambled.
This hasn't been noticed, because the checkasm test erroneously
only checked half of the output (for 8 bit functions), and
apparently none of the samples as part of "fate-hevc" seem to
trigger this specific function.
---
libavcodec/aarch64/hevcdsp_epel_neon.S | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S
b/libavcodec/aarch64/hevcdsp_epel_neon.S
index 2dafa09337..d3f0a26f79 100644
--- a/libavcodec/aarch64/hevcdsp_epel_neon.S
+++ b/libavcodec/aarch64/hevcdsp_epel_neon.S
@@ -1572,6 +1572,7 @@ function ff_hevc_put_hevc_epel_h48_8_neon_i8mm, export=1
xtn2v22.8h, v26.4s
xtn v23.4h, v23.4s
xtn2v23.8h, v27.4s
+add x7, x0, #64
st4 {v20.8h, v21.8h, v22.8h, v23.8h}, [x0], x10
ext v4.16b, v2.16b, v3.16b, #1
ext v5.16b, v2.16b, v3.16b, #2
@@ -1584,11 +1585,14 @@ function ff_hevc_put_hevc_epel_h48_8_neon_i8mm, export=1
usdot v21.4s, v4.16b, v30.16b
usdot v22.4s, v5.16b, v30.16b
usdot v23.4s, v6.16b, v30.16b
-xtn v20.4h, v20.4s
-xtn2v20.8h, v22.4s
-xtn v21.4h, v21.4s
-xtn2v21.8h, v23.4s
-add x7, x0, #64
+zip1v24.4s, v20.4s, v22.4s
+zip2v25.4s, v20.4s, v22.4s
+zip1v26.4s, v21.4s, v23.4s
+zip2v27.4s, v21.4s, v23.4s
+xtn v20.4h, v24.4s
+xtn2v20.8h, v25.4s
+xtn v21.4h, v26.4s
+xtn2v21.8h, v27.4s
st2 {v20.8h, v21.8h}, [x7]
b.ne1b
ret
--
2.39.3 (Apple Git-146)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] checkasm: hevc_pel: Check the full output in hevc_epel/hevc_qpel
Previously it only checked half the output in 8 bit per pixel mode,
as the output actually is 16 bit elements here.
---
tests/checkasm/hevc_pel.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/tests/checkasm/hevc_pel.c b/tests/checkasm/hevc_pel.c
index f9a7a7717c..065da87622 100644
--- a/tests/checkasm/hevc_pel.c
+++ b/tests/checkasm/hevc_pel.c
@@ -102,7 +102,7 @@ static void checkasm_check_hevc_qpel(void)
call_ref(dstw0, src0, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
call_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
for (row = 0; row < size[sizes]; row++) {
-if (memcmp(dstw0 + row * MAX_PB_SIZE, dstw1 + row
* MAX_PB_SIZE, sizes[size] * SIZEOF_PIXEL))
+if (memcmp(dstw0 + row * MAX_PB_SIZE, dstw1 + row
* MAX_PB_SIZE, sizes[size] * sizeof(int16_t)))
fail();
}
bench_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
@@ -334,7 +334,7 @@ static void checkasm_check_hevc_epel(void)
call_ref(dstw0, src0, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
call_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
for (row = 0; row < size[sizes]; row++) {
-if (memcmp(dstw0 + row * MAX_PB_SIZE, dstw1 + row
* MAX_PB_SIZE, sizes[size] * SIZEOF_PIXEL))
+if (memcmp(dstw0 + row * MAX_PB_SIZE, dstw1 + row
* MAX_PB_SIZE, sizes[size] * sizeof(int16_t)))
fail();
}
bench_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
--
2.39.3 (Apple Git-146)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] checkasm: hevc_pel: Split a couple excessively long lines
---
tests/checkasm/hevc_pel.c | 134 --
1 file changed, 98 insertions(+), 36 deletions(-)
diff --git a/tests/checkasm/hevc_pel.c b/tests/checkasm/hevc_pel.c
index 065da87622..73a4619978 100644
--- a/tests/checkasm/hevc_pel.c
+++ b/tests/checkasm/hevc_pel.c
@@ -96,13 +96,16 @@ static void checkasm_check_hevc_qpel(void)
case 3: type = "qpel_hv"; break; // 1 1
}
-if (check_func(h.put_hevc_qpel[size][j][i],
"put_hevc_%s%d_%d", type, sizes[size], bit_depth)) {
+if (check_func(h.put_hevc_qpel[size][j][i],
+ "put_hevc_%s%d_%d", type, sizes[size],
bit_depth)) {
int16_t *dstw0 = (int16_t *) dst0, *dstw1 = (int16_t
*) dst1;
randomize_buffers();
call_ref(dstw0, src0, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
call_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
for (row = 0; row < size[sizes]; row++) {
-if (memcmp(dstw0 + row * MAX_PB_SIZE, dstw1 + row
* MAX_PB_SIZE, sizes[size] * sizeof(int16_t)))
+if (memcmp(dstw0 + row * MAX_PB_SIZE,
+ dstw1 + row * MAX_PB_SIZE,
+ sizes[size] * sizeof(int16_t)))
fail();
}
bench_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
@@ -140,13 +143,20 @@ static void checkasm_check_hevc_qpel_uni(void)
case 3: type = "qpel_uni_hv"; break; // 1 1
}
-if (check_func(h.put_hevc_qpel_uni[size][j][i],
"put_hevc_%s%d_%d", type, sizes[size], bit_depth)) {
+if (check_func(h.put_hevc_qpel_uni[size][j][i],
+ "put_hevc_%s%d_%d", type, sizes[size],
bit_depth)) {
randomize_buffers();
-call_ref(dst0, sizes[size] * SIZEOF_PIXEL, src0,
sizes[size] * SIZEOF_PIXEL, sizes[size], i, j, sizes[size]);
-call_new(dst1, sizes[size] * SIZEOF_PIXEL, src1,
sizes[size] * SIZEOF_PIXEL, sizes[size], i, j, sizes[size]);
+call_ref(dst0, sizes[size] * SIZEOF_PIXEL,
+ src0, sizes[size] * SIZEOF_PIXEL,
+ sizes[size], i, j, sizes[size]);
+call_new(dst1, sizes[size] * SIZEOF_PIXEL,
+ src1, sizes[size] * SIZEOF_PIXEL,
+ sizes[size], i, j, sizes[size]);
if (memcmp(dst0, dst1, sizes[size] * sizes[size] *
SIZEOF_PIXEL))
fail();
-bench_new(dst1, sizes[size] * SIZEOF_PIXEL, src1,
sizes[size] * SIZEOF_PIXEL, sizes[size], i, j, sizes[size]);
+bench_new(dst1, sizes[size] * SIZEOF_PIXEL,
+ src1, sizes[size] * SIZEOF_PIXEL,
+ sizes[size], i, j, sizes[size]);
}
}
}
@@ -182,16 +192,23 @@ static void checkasm_check_hevc_qpel_uni_w(void)
case 3: type = "qpel_uni_w_hv"; break; // 1 1
}
-if (check_func(h.put_hevc_qpel_uni_w[size][j][i],
"put_hevc_%s%d_%d", type, sizes[size], bit_depth)) {
+if (check_func(h.put_hevc_qpel_uni_w[size][j][i],
+ "put_hevc_%s%d_%d", type, sizes[size],
bit_depth)) {
for (denom = denoms; *denom >= 0; denom++) {
for (wx = weights; *wx >= 0; wx++) {
for (ox = offsets; *ox >= 0; ox++) {
randomize_buffers();
-call_ref(dst0, sizes[size] * SIZEOF_PIXEL,
src0, sizes[size] * SIZEOF_PIXEL, sizes[size], *denom, *wx, *ox, i, j,
sizes[size]);
-call_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL, sizes[size], *denom, *wx, *ox, i, j,
sizes[size]);
+call_ref(dst0, sizes[size] * SIZEOF_PIXEL,
+ src0, sizes[size] * SIZEOF_PIXEL,
+ sizes[size], *denom, *wx, *ox, i,
j, sizes[size]);
+call_new(dst1, sizes[size] * SIZEOF_PIXEL,
+ src1, sizes[size] * SIZEOF_PIXEL,
+ sizes[size], *denom, *wx, *ox, i,
j, sizes[size]);
if (memcmp(dst0, dst1, sizes[size] *
sizes[size] * SIZEO
[FFmpeg-devel] [PATCH 4/4] checkasm: hevc_pel: Use checkasm_check for printing failing output
This simplifies the code for checking the output, and can print
the failing output (including a map of matching/mismatching
elements) if checkasm is run with the -v/--verbose option.
---
tests/checkasm/hevc_pel.c | 71 ++-
1 file changed, 41 insertions(+), 30 deletions(-)
diff --git a/tests/checkasm/hevc_pel.c b/tests/checkasm/hevc_pel.c
index 73a4619978..ed22ec4f9d 100644
--- a/tests/checkasm/hevc_pel.c
+++ b/tests/checkasm/hevc_pel.c
@@ -36,6 +36,15 @@ static const int offsets[] = {0, 255, -1 };
#define SIZEOF_PIXEL ((bit_depth + 7) / 8)
#define BUF_SIZE (2 * MAX_PB_SIZE * (2 * 4 + MAX_PB_SIZE))
+#define checkasm_check_pixel(buf1, stride1, buf2, stride2, ...) \
+((bit_depth > 8) ? \
+ checkasm_check(uint16_t, (const uint16_t*)buf1, stride1, \
+ (const uint16_t*)buf2, stride2, \
+ __VA_ARGS__) :\
+ checkasm_check(uint8_t, (const uint8_t*) buf1, stride1, \
+ (const uint8_t*) buf2, stride2, \
+ __VA_ARGS__))
+
#define randomize_buffers() \
do { \
uint32_t mask = pixel_mask[bit_depth - 8]; \
@@ -78,7 +87,7 @@ static void checkasm_check_hevc_qpel(void)
LOCAL_ALIGNED_32(uint8_t, dst1, [BUF_SIZE]);
HEVCDSPContext h;
-int size, bit_depth, i, j, row;
+int size, bit_depth, i, j;
declare_func(void, int16_t *dst, uint8_t *src, ptrdiff_t srcstride,
int height, intptr_t mx, intptr_t my, int width);
@@ -102,12 +111,9 @@ static void checkasm_check_hevc_qpel(void)
randomize_buffers();
call_ref(dstw0, src0, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
call_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
-for (row = 0; row < size[sizes]; row++) {
-if (memcmp(dstw0 + row * MAX_PB_SIZE,
- dstw1 + row * MAX_PB_SIZE,
- sizes[size] * sizeof(int16_t)))
-fail();
-}
+checkasm_check(int16_t, dstw0, MAX_PB_SIZE *
sizeof(int16_t),
+dstw1, MAX_PB_SIZE *
sizeof(int16_t),
+size[sizes], size[sizes],
"dst");
bench_new(dstw1, src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
}
}
@@ -152,8 +158,9 @@ static void checkasm_check_hevc_qpel_uni(void)
call_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
-if (memcmp(dst0, dst1, sizes[size] * sizes[size] *
SIZEOF_PIXEL))
-fail();
+checkasm_check_pixel(dst0, sizes[size] * SIZEOF_PIXEL,
+ dst1, sizes[size] * SIZEOF_PIXEL,
+ size[sizes], size[sizes], "dst");
bench_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], i, j, sizes[size]);
@@ -204,8 +211,9 @@ static void checkasm_check_hevc_qpel_uni_w(void)
call_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], *denom, *wx, *ox, i,
j, sizes[size]);
-if (memcmp(dst0, dst1, sizes[size] *
sizes[size] * SIZEOF_PIXEL))
-fail();
+checkasm_check_pixel(dst0, sizes[size] *
SIZEOF_PIXEL,
+ dst1, sizes[size] *
SIZEOF_PIXEL,
+ size[sizes],
size[sizes], "dst");
bench_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL,
sizes[size], *denom, *wx, *ox,
i, j, sizes[size]);
@@ -258,8 +266,9 @@ static void checkasm_check_hevc_qpel_bi(void)
call_new(dst1, sizes[size] * SIZEOF_PIXEL,
src1, sizes[size] * SIZEOF_PIXEL,
ref1, sizes[size], i, j, sizes[size]);
-if (memcmp(dst0, dst1, sizes[size] * sizes[size] *
SIZEOF_PIXEL))
-
Re: [FFmpeg-devel] [PATCH v3 2/6] avcodec/ccaption_dec: don't print multiple \an and \pos tags
On date Tuesday 2024-03-12 01:00:01 -0500, Marth64 wrote:
> Closed Captions decoder prints multiple \pos ASS tags per cue,
> and preceding the \pos tag is a fixed \an7 that fixes rendering
> position from the top left corner and enforces justification.
>
> Printing multiple \an and \pos tags in this way is invalid behavior,
> because only the first \pos tag in a cue is honored by ASS anyway.
> Don't write multiple \an and \pos tags.
>
> Also, update tests accordingly.
>
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 8 +-
> tests/ref/fate/sub-cc | 2 +-
> tests/ref/fate/sub-cc-realtime | 8 +-
> tests/ref/fate/sub-cc-scte20 | 4 +-
> tests/ref/fate/sub-scc | 146 -
> 5 files changed, 86 insertions(+), 82 deletions(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index faf058ce97..9d4a93647c 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -456,7 +456,7 @@ static void roll_up(CCaptionSubContext *ctx)
>
> static int capture_screen(CCaptionSubContext *ctx)
> {
> -int i, j, tab = 0;
> +int i, j, tab = 0, seen_row = 0;
> struct Screen *screen = ctx->screen + ctx->active_screen;
> enum cc_font prev_font = CCFONT_REGULAR;
> enum cc_color_code prev_color = CCCOL_WHITE;
> @@ -496,7 +496,11 @@ static int capture_screen(CCaptionSubContext *ctx)
>
> x = ASS_DEFAULT_PLAYRESX * (0.1 + 0.0250 * j);
> y = ASS_DEFAULT_PLAYRESY * (0.1 + 0.0533 * i);
> -av_bprintf(&ctx->buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x, y);
> +
> +if (!seen_row) {
> +av_bprintf(&ctx->buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x,
> y);
> +seen_row = 1;
> +}
probably it might be useful to print debug logs in case the pos
coordinates are found but not rendered?
[...]
LGTM otherwise.
___
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 3/6] avcodec/ccaption_dec: ignore leading non-breaking spaces
On date Tuesday 2024-03-12 01:00:02 -0500, Marth64 wrote: > In Closed Captions (US), the non-breaking space (0xA0) can be used to > align text horizontally from the left when used as a leading character. > However, CC decoder does not ignore it as a leading character > like it does an ordinary space, so a blank padding is rendered > on the black CC box. This is not the intended viewing experience. > > Ignore the leading non-breaking spaces, thus creating the intended > transparency which aligns the text. Since all characters are > fixed-width in CC, it can be handled the same way as we currently > treat leading ordinary spaces. > > Also, as a nit, lowercase the NBSP's hex code in the entry table to match > casing of the other hex codes. > > Signed-off-by: Marth64 > --- > libavcodec/ccaption_dec.c | 9 ++--- > 1 file changed, 6 insertions(+), 3 deletions(-) Still 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 v3 4/6] avcodec/rcwtenc: canonize name and refresh documentation
On date Tuesday 2024-03-12 01:00:03 -0500, Marth64 wrote: > The formal title of the muxer according to the specification > is "RCWT (Raw Captions With Time)", so canonize this > in the long name of the codec and docs. > > In the documentation section, point #2 was wrong: ccextractor > extracts the Closed Captions data and stores normalized bits > similarly to this muxer. > > Signed-off-by: Marth64 > --- > libavformat/rcwtenc.c | 21 +++-- > 1 file changed, 7 insertions(+), 14 deletions(-) LGTM, will apply. ___ 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 6/6] avformat/sccdec: remove unused bprint.h include
On date Tuesday 2024-03-12 01:00:05 -0500, Marth64 wrote: > Signed-off-by: Marth64 > --- > libavformat/sccdec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavformat/sccdec.c b/libavformat/sccdec.c > index 5f2f95d80e..f6d5f29a0a 100644 > --- a/libavformat/sccdec.c > +++ b/libavformat/sccdec.c > @@ -24,7 +24,6 @@ > #include "internal.h" > #include "subtitles.h" > #include "libavutil/avstring.h" > -#include "libavutil/bprint.h" > #include "libavutil/intreadwrite.h" Will apply, 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] [PATCH v4] avcodec/libx264: fix extradata when config annexb=0
From: Zhao Zhili
---
v4: Fix missing SEI in set_avcc_extradata
v3: Remove unnecessary inclusion
configure| 2 +-
libavcodec/libx264.c | 153 ---
2 files changed, 130 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index db7dc89755..24cb897d28 100755
--- a/configure
+++ b/configure
@@ -3491,7 +3491,7 @@ libwebp_encoder_deps="libwebp"
libwebp_anim_encoder_deps="libwebp"
libx262_encoder_deps="libx262"
libx264_encoder_deps="libx264"
-libx264_encoder_select="atsc_a53"
+libx264_encoder_select="atsc_a53 h264parse"
libx264rgb_encoder_deps="libx264"
libx264rgb_encoder_select="libx264_encoder"
libx265_encoder_deps="libx265"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 10d646bd76..e7d16997d2 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -34,6 +34,7 @@
#include "avcodec.h"
#include "codec_internal.h"
#include "encode.h"
+#include "h264_ps.h"
#include "internal.h"
#include "packet_internal.h"
#include "atsc_a53.h"
@@ -865,6 +866,131 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
return 0;
}
+static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
+{
+X264Context *x4 = avctx->priv_data;
+
+av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
+x4->sei_size = nal->i_payload;
+x4->sei = av_malloc(x4->sei_size);
+if (!x4->sei)
+return AVERROR(ENOMEM);
+
+memcpy(x4->sei, nal->p_payload, nal->i_payload);
+
+return 0;
+}
+
+static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int nnal)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *sps_nal = NULL;
+x264_nal_t *pps_nal = NULL;
+uint8_t *p, *sps;
+int ret;
+
+/* We know it's in the order of SPS/PPS/SEI, but it's not documented in
x264 API.
+ * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
+ */
+for (int i = 0; i < nnal; i++) {
+switch (nal[i].i_type) {
+case NAL_SPS:
+sps_nal = &nal[i];
+break;
+case NAL_PPS:
+pps_nal = &nal[i];
+break;
+case NAL_SEI:
+ret = save_sei(avctx, &nal[i]);
+if (ret < 0)
+return ret;
+break;
+}
+}
+if (!sps_nal || !pps_nal)
+return AVERROR_EXTERNAL;
+
+avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
+avctx->extradata = av_mallocz(avctx->extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!avctx->extradata)
+return AVERROR(ENOMEM);
+
+// Now create AVCDecoderConfigurationRecord
+p = avctx->extradata;
+// Skip size part
+sps = sps_nal->p_payload + 4;
+*p++ = 1; // version
+*p++ = sps[1]; // AVCProfileIndication
+*p++ = sps[2]; // profile_compatibility
+*p++ = sps[3]; // AVCLevelIndication
+*p++ = 0xFF;
+*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
+memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
+// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
+// with GetBitContext
+sps = p + 2;
+p += sps_nal->i_payload - 2;
+*p++ = 1;
+memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
+p += pps_nal->i_payload - 2;
+
+if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
+GetBitContext gbc;
+H264ParamSets ps = { 0 };
+
+init_get_bits8(&gbc, sps, sps_nal->i_payload - 4);
+skip_bits(&gbc, 8);
+ret = ff_h264_decode_seq_parameter_set(&gbc, avctx, &ps, 1);
+if (ret < 0)
+return ret;
+
+ps.sps = ps.sps_list[x4->params.i_sps_id];
+*p++ = 0xFC | ps.sps->chroma_format_idc;
+*p++ = 0xF8 | (ps.sps->bit_depth_luma - 8);
+*p++ = 0xF8 | (ps.sps->bit_depth_chroma - 8);
+*p++ = 0;
+ff_h264_ps_uninit(&ps);
+}
+av_assert0(avctx->extradata + avctx->extradata_size >= p);
+avctx->extradata_size = p - avctx->extradata;
+
+return 0;
+}
+
+static int set_extradata(AVCodecContext *avctx)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *nal;
+uint8_t *p;
+int nnal, s;
+
+s = x264_encoder_headers(x4->enc, &nal, &nnal);
+if (s < 0)
+return AVERROR_EXTERNAL;
+
+if (!x4->params.b_annexb)
+return set_avcc_extradata(avctx, nal, nnal);
+
+avctx->extradata = p = av_mallocz(s + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!p)
+return AVERROR(ENOMEM);
+
+for (int i = 0; i < nnal; i++) {
+/* Don't put the SEI in extradata. */
+if (nal[i].i_type == NAL_SEI) {
+s = save_sei(avctx, &nal[i]);
+if (s < 0)
+return s;
+continue;
+}
+memcpy(p, nal[i].p_payload, nal[i].i_payload);
+p += nal[i].i_payload;
+}
+avctx->extradata_size = p - avctx->extradata;
+
+return 0;
+}
+
#define PARSE_X264_OPT(name, var)\
if (x4->var && x264_param
Re: [FFmpeg-devel] [PATCH v3 5/6] avformat/rcwtdec: add RCWT Closed Captions demuxer
Will address, thanks for the review. ___ 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/tiff: Use ff_tget_long() where appropriate
No need to use the generic ff_tget() when we know the type.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/tiff.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 8f278bfd12..3238b208d8 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -1269,8 +1269,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
value = ff_tget(&s->gb, type, s->le);
break;
case TIFF_RATIONAL:
-value = ff_tget(&s->gb, TIFF_LONG, s->le);
-value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+value = ff_tget_long(&s->gb, s->le);
+value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator in
rational\n");
value2 = 1;
@@ -1437,7 +1437,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
if (count == 1)
s->sub_ifd = value;
else if (count > 1)
-s->sub_ifd = ff_tget(&s->gb, TIFF_LONG, s->le); /** Only get the
first SubIFD */
+s->sub_ifd = ff_tget_long(&s->gb, s->le); /** Only get the first
SubIFD */
break;
case TIFF_GRAY_RESPONSE_CURVE:
case DNG_LINEARIZATION_TABLE:
@@ -1453,8 +1453,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
s->black_level[0] = value / (float)value2;
for (int i = 0; i < count && count > 1; i++) {
if (type == TIFF_RATIONAL) {
-value = ff_tget(&s->gb, TIFF_LONG, s->le);
-value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+value = ff_tget_long(&s->gb, s->le);
+value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator\n");
value2 = 1;
@@ -1462,8 +1462,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
s->black_level[i] = value / (float)value2;
} else if (type == TIFF_SRATIONAL) {
-int value = ff_tget(&s->gb, TIFF_LONG, s->le);
-int value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+int value = ff_tget_long(&s->gb, s->le);
+int value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator\n");
value2 = 1;
@@ -1740,7 +1740,7 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
// need to seek back to re-read the page number
bytestream2_seek(&s->gb, -count * sizeof(uint16_t), SEEK_CUR);
// read the page number
-s->cur_page = ff_tget(&s->gb, TIFF_SHORT, s->le);
+s->cur_page = ff_tget_short(&s->gb, s->le);
// get back to where we were before the previous seek
bytestream2_seek(&s->gb, count * sizeof(uint16_t) - sizeof(uint16_t),
SEEK_CUR);
break;
@@ -1766,8 +1766,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
break;
for (int i = 0; i < 3; i++) {
-value = ff_tget(&s->gb, TIFF_LONG, s->le);
-value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+value = ff_tget_long(&s->gb, s->le);
+value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator\n");
value2 = 1;
@@ -1781,8 +1781,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
break;
for (int i = 0; i < 3; i++) {
-value = ff_tget(&s->gb, TIFF_LONG, s->le);
-value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+value = ff_tget_long(&s->gb, s->le);
+value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator\n");
value2 = 1;
@@ -1796,8 +1796,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
break;
for (int i = 0; i < 2; i++) {
-value = ff_tget(&s->gb, TIFF_LONG, s->le);
-value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+value = ff_tget_long(&s->gb, s->le);
+value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
av_log(s->avctx, AV_LOG_WARNING, "Invalid denominator\n");
value2 = 1;
@@ -1814,8 +1814,8 @@ static int tiff_decode_tag(TiffContext *s, AVFrame *frame)
case DNG_COLOR_MATRIX2:
for (int i = 0; i < 3; i++) {
for (int j = 0; j < 3; j++) {
-int value = ff_tget(&s->gb, TIFF_LONG, s->le);
-int value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
+int value = ff_tget_long(&s->gb, s->le);
+int value2 = ff_tget_long(&s->gb, s->le);
if (!value2) {
Re: [FFmpeg-devel] [PATCH v4] avcodec/libx264: fix extradata when config annexb=0
Zhao Zhili:
> From: Zhao Zhili
>
> ---
> v4: Fix missing SEI in set_avcc_extradata
> v3: Remove unnecessary inclusion
>
> configure| 2 +-
> libavcodec/libx264.c | 153 ---
> 2 files changed, 130 insertions(+), 25 deletions(-)
>
> diff --git a/configure b/configure
> index db7dc89755..24cb897d28 100755
> --- a/configure
> +++ b/configure
> @@ -3491,7 +3491,7 @@ libwebp_encoder_deps="libwebp"
> libwebp_anim_encoder_deps="libwebp"
> libx262_encoder_deps="libx262"
> libx264_encoder_deps="libx264"
> -libx264_encoder_select="atsc_a53"
> +libx264_encoder_select="atsc_a53 h264parse"
> libx264rgb_encoder_deps="libx264"
> libx264rgb_encoder_select="libx264_encoder"
> libx265_encoder_deps="libx265"
> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
> index 10d646bd76..e7d16997d2 100644
> --- a/libavcodec/libx264.c
> +++ b/libavcodec/libx264.c
> @@ -34,6 +34,7 @@
> #include "avcodec.h"
> #include "codec_internal.h"
> #include "encode.h"
> +#include "h264_ps.h"
> #include "internal.h"
> #include "packet_internal.h"
> #include "atsc_a53.h"
> @@ -865,6 +866,131 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
> return 0;
> }
>
> +static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
> +{
> +X264Context *x4 = avctx->priv_data;
> +
> +av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
> +x4->sei_size = nal->i_payload;
> +x4->sei = av_malloc(x4->sei_size);
> +if (!x4->sei)
> +return AVERROR(ENOMEM);
> +
> +memcpy(x4->sei, nal->p_payload, nal->i_payload);
> +
> +return 0;
> +}
> +
> +static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int
> nnal)
> +{
> +X264Context *x4 = avctx->priv_data;
> +x264_nal_t *sps_nal = NULL;
> +x264_nal_t *pps_nal = NULL;
> +uint8_t *p, *sps;
> +int ret;
> +
> +/* We know it's in the order of SPS/PPS/SEI, but it's not documented in
> x264 API.
> + * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
> + */
> +for (int i = 0; i < nnal; i++) {
> +switch (nal[i].i_type) {
> +case NAL_SPS:
> +sps_nal = &nal[i];
> +break;
> +case NAL_PPS:
> +pps_nal = &nal[i];
> +break;
> +case NAL_SEI:
> +ret = save_sei(avctx, &nal[i]);
> +if (ret < 0)
> +return ret;
> +break;
> +}
> +}
> +if (!sps_nal || !pps_nal)
> +return AVERROR_EXTERNAL;
> +
> +avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
> +avctx->extradata = av_mallocz(avctx->extradata_size +
> AV_INPUT_BUFFER_PADDING_SIZE);
> +if (!avctx->extradata)
> +return AVERROR(ENOMEM);
> +
> +// Now create AVCDecoderConfigurationRecord
> +p = avctx->extradata;
> +// Skip size part
> +sps = sps_nal->p_payload + 4;
> +*p++ = 1; // version
> +*p++ = sps[1]; // AVCProfileIndication
> +*p++ = sps[2]; // profile_compatibility
> +*p++ = sps[3]; // AVCLevelIndication
> +*p++ = 0xFF;
> +*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
> +memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
> +// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
> +// with GetBitContext
> +sps = p + 2;
> +p += sps_nal->i_payload - 2;
> +*p++ = 1;
> +memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
> +p += pps_nal->i_payload - 2;
> +
> +if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
> +GetBitContext gbc;
> +H264ParamSets ps = { 0 };
> +
> +init_get_bits8(&gbc, sps, sps_nal->i_payload - 4);
> +skip_bits(&gbc, 8);
> +ret = ff_h264_decode_seq_parameter_set(&gbc, avctx, &ps, 1);
ff_h264_decode_seq_parameter_set() expects to read from a GetBitContext
whose buffer has already been stripped of 0x03 escape bytes. Your buffer
hasn't and therefore it is possible for this function to return an error
even when the input is fine.
> +if (ret < 0)
> +return ret;
> +
> +ps.sps = ps.sps_list[x4->params.i_sps_id];
> +*p++ = 0xFC | ps.sps->chroma_format_idc;
> +*p++ = 0xF8 | (ps.sps->bit_depth_luma - 8);
> +*p++ = 0xF8 | (ps.sps->bit_depth_chroma - 8);
> +*p++ = 0;
> +ff_h264_ps_uninit(&ps);
> +}
> +av_assert0(avctx->extradata + avctx->extradata_size >= p);
> +avctx->extradata_size = p - avctx->extradata;
> +
> +return 0;
> +}
> +
> +static int set_extradata(AVCodecContext *avctx)
> +{
> +X264Context *x4 = avctx->priv_data;
> +x264_nal_t *nal;
> +uint8_t *p;
> +int nnal, s;
> +
> +s = x264_encoder_headers(x4->enc, &nal, &nnal);
> +if (s < 0)
> +return AVERROR_EXTERNAL;
> +
> +if (!x4->params.b_annexb)
> +return set_avcc_extradata(avctx, nal, nnal);
> +
> +avctx->extradata = p = av_mallocz(s + AV_INPUT_
Re: [FFmpeg-devel] [PATCH v4] avcodec/libx264: fix extradata when config annexb=0
On 3/12/2024 12:00 PM, Andreas Rheinhardt wrote:
Zhao Zhili:
From: Zhao Zhili
---
v4: Fix missing SEI in set_avcc_extradata
v3: Remove unnecessary inclusion
configure| 2 +-
libavcodec/libx264.c | 153 ---
2 files changed, 130 insertions(+), 25 deletions(-)
diff --git a/configure b/configure
index db7dc89755..24cb897d28 100755
--- a/configure
+++ b/configure
@@ -3491,7 +3491,7 @@ libwebp_encoder_deps="libwebp"
libwebp_anim_encoder_deps="libwebp"
libx262_encoder_deps="libx262"
libx264_encoder_deps="libx264"
-libx264_encoder_select="atsc_a53"
+libx264_encoder_select="atsc_a53 h264parse"
libx264rgb_encoder_deps="libx264"
libx264rgb_encoder_select="libx264_encoder"
libx265_encoder_deps="libx265"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 10d646bd76..e7d16997d2 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -34,6 +34,7 @@
#include "avcodec.h"
#include "codec_internal.h"
#include "encode.h"
+#include "h264_ps.h"
#include "internal.h"
#include "packet_internal.h"
#include "atsc_a53.h"
@@ -865,6 +866,131 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
return 0;
}
+static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
+{
+X264Context *x4 = avctx->priv_data;
+
+av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
+x4->sei_size = nal->i_payload;
+x4->sei = av_malloc(x4->sei_size);
+if (!x4->sei)
+return AVERROR(ENOMEM);
+
+memcpy(x4->sei, nal->p_payload, nal->i_payload);
+
+return 0;
+}
+
+static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t *nal, int nnal)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *sps_nal = NULL;
+x264_nal_t *pps_nal = NULL;
+uint8_t *p, *sps;
+int ret;
+
+/* We know it's in the order of SPS/PPS/SEI, but it's not documented in
x264 API.
+ * The x264 param i_sps_id implies there is a single pair of SPS/PPS.
+ */
+for (int i = 0; i < nnal; i++) {
+switch (nal[i].i_type) {
+case NAL_SPS:
+sps_nal = &nal[i];
+break;
+case NAL_PPS:
+pps_nal = &nal[i];
+break;
+case NAL_SEI:
+ret = save_sei(avctx, &nal[i]);
+if (ret < 0)
+return ret;
+break;
+}
+}
+if (!sps_nal || !pps_nal)
+return AVERROR_EXTERNAL;
+
+avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload + 7;
+avctx->extradata = av_mallocz(avctx->extradata_size +
AV_INPUT_BUFFER_PADDING_SIZE);
+if (!avctx->extradata)
+return AVERROR(ENOMEM);
+
+// Now create AVCDecoderConfigurationRecord
+p = avctx->extradata;
+// Skip size part
+sps = sps_nal->p_payload + 4;
+*p++ = 1; // version
+*p++ = sps[1]; // AVCProfileIndication
+*p++ = sps[2]; // profile_compatibility
+*p++ = sps[3]; // AVCLevelIndication
+*p++ = 0xFF;
+*p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
+memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
+// Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can be used
+// with GetBitContext
+sps = p + 2;
+p += sps_nal->i_payload - 2;
+*p++ = 1;
+memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
+p += pps_nal->i_payload - 2;
+
+if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
+GetBitContext gbc;
+H264ParamSets ps = { 0 };
+
+init_get_bits8(&gbc, sps, sps_nal->i_payload - 4);
+skip_bits(&gbc, 8);
+ret = ff_h264_decode_seq_parameter_set(&gbc, avctx, &ps, 1);
ff_h264_decode_seq_parameter_set() expects to read from a GetBitContext
whose buffer has already been stripped of 0x03 escape bytes. Your buffer
hasn't and therefore it is possible for this function to return an error
even when the input is fine.
Why would a buffer created by passing annexb=0 have the escape bytes? Is
it not specific to that encapsulation, to prevent parsing image data as
a start code?
+if (ret < 0)
+return ret;
+
+ps.sps = ps.sps_list[x4->params.i_sps_id];
+*p++ = 0xFC | ps.sps->chroma_format_idc;
+*p++ = 0xF8 | (ps.sps->bit_depth_luma - 8);
+*p++ = 0xF8 | (ps.sps->bit_depth_chroma - 8);
+*p++ = 0;
+ff_h264_ps_uninit(&ps);
+}
+av_assert0(avctx->extradata + avctx->extradata_size >= p);
+avctx->extradata_size = p - avctx->extradata;
+
+return 0;
+}
+
+static int set_extradata(AVCodecContext *avctx)
+{
+X264Context *x4 = avctx->priv_data;
+x264_nal_t *nal;
+uint8_t *p;
+int nnal, s;
+
+s = x264_encoder_headers(x4->enc, &nal, &nnal);
+if (s < 0)
+return AVERROR_EXTERNAL;
+
+if (!x4->params.b_annexb)
+return set_avcc_extradata(avctx, nal, nnal);
+
+avctx->extradata = p = av_mallocz(s + AV_INPUT_BUFFER_PADDING_SIZE);
+if (!p)
+return AVERROR
[FFmpeg-devel] [PATCH] avformat/dvdvideodec: use correct format string for menu read error, fixes compiler warning
Signed-off-by: Marth64
---
libavformat/dvdvideodec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index a182f95097..0ae2110cd2 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -423,7 +423,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
blocks_read = DVDReadBlocks(state->vob_file, state->sector_offset, 1,
read_buf);
if (blocks_read != 1) {
-av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%d\n",
+av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%ld\n",
state->sector_offset, blocks_read);
return AVERROR_INVALIDDATA;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4] avcodec/libx264: fix extradata when config annexb=0
James Almer:
> On 3/12/2024 12:00 PM, Andreas Rheinhardt wrote:
>> Zhao Zhili:
>>> From: Zhao Zhili
>>>
>>> ---
>>> v4: Fix missing SEI in set_avcc_extradata
>>> v3: Remove unnecessary inclusion
>>>
>>> configure | 2 +-
>>> libavcodec/libx264.c | 153 ---
>>> 2 files changed, 130 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index db7dc89755..24cb897d28 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3491,7 +3491,7 @@ libwebp_encoder_deps="libwebp"
>>> libwebp_anim_encoder_deps="libwebp"
>>> libx262_encoder_deps="libx262"
>>> libx264_encoder_deps="libx264"
>>> -libx264_encoder_select="atsc_a53"
>>> +libx264_encoder_select="atsc_a53 h264parse"
>>> libx264rgb_encoder_deps="libx264"
>>> libx264rgb_encoder_select="libx264_encoder"
>>> libx265_encoder_deps="libx265"
>>> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>>> index 10d646bd76..e7d16997d2 100644
>>> --- a/libavcodec/libx264.c
>>> +++ b/libavcodec/libx264.c
>>> @@ -34,6 +34,7 @@
>>> #include "avcodec.h"
>>> #include "codec_internal.h"
>>> #include "encode.h"
>>> +#include "h264_ps.h"
>>> #include "internal.h"
>>> #include "packet_internal.h"
>>> #include "atsc_a53.h"
>>> @@ -865,6 +866,131 @@ static int convert_pix_fmt(enum AVPixelFormat
>>> pix_fmt)
>>> return 0;
>>> }
>>> +static int save_sei(AVCodecContext *avctx, x264_nal_t *nal)
>>> +{
>>> + X264Context *x4 = avctx->priv_data;
>>> +
>>> + av_log(avctx, AV_LOG_INFO, "%s\n", nal->p_payload + 25);
>>> + x4->sei_size = nal->i_payload;
>>> + x4->sei = av_malloc(x4->sei_size);
>>> + if (!x4->sei)
>>> + return AVERROR(ENOMEM);
>>> +
>>> + memcpy(x4->sei, nal->p_payload, nal->i_payload);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> +static int set_avcc_extradata(AVCodecContext *avctx, x264_nal_t
>>> *nal, int nnal)
>>> +{
>>> + X264Context *x4 = avctx->priv_data;
>>> + x264_nal_t *sps_nal = NULL;
>>> + x264_nal_t *pps_nal = NULL;
>>> + uint8_t *p, *sps;
>>> + int ret;
>>> +
>>> + /* We know it's in the order of SPS/PPS/SEI, but it's not
>>> documented in x264 API.
>>> + * The x264 param i_sps_id implies there is a single pair of
>>> SPS/PPS.
>>> + */
>>> + for (int i = 0; i < nnal; i++) {
>>> + switch (nal[i].i_type) {
>>> + case NAL_SPS:
>>> + sps_nal = &nal[i];
>>> + break;
>>> + case NAL_PPS:
>>> + pps_nal = &nal[i];
>>> + break;
>>> + case NAL_SEI:
>>> + ret = save_sei(avctx, &nal[i]);
>>> + if (ret < 0)
>>> + return ret;
>>> + break;
>>> + }
>>> + }
>>> + if (!sps_nal || !pps_nal)
>>> + return AVERROR_EXTERNAL;
>>> +
>>> + avctx->extradata_size = sps_nal->i_payload + pps_nal->i_payload
>>> + 7;
>>> + avctx->extradata = av_mallocz(avctx->extradata_size +
>>> AV_INPUT_BUFFER_PADDING_SIZE);
>>> + if (!avctx->extradata)
>>> + return AVERROR(ENOMEM);
>>> +
>>> + // Now create AVCDecoderConfigurationRecord
>>> + p = avctx->extradata;
>>> + // Skip size part
>>> + sps = sps_nal->p_payload + 4;
>>> + *p++ = 1; // version
>>> + *p++ = sps[1]; // AVCProfileIndication
>>> + *p++ = sps[2]; // profile_compatibility
>>> + *p++ = sps[3]; // AVCLevelIndication
>>> + *p++ = 0xFF;
>>> + *p++ = 0xE0 | 0x01; // 3 bits reserved (111) + 5 bits number of sps
>>> + memcpy(p, sps_nal->p_payload + 2, sps_nal->i_payload - 2);
>>> + // Make sps has AV_INPUT_BUFFER_PADDING_SIZE padding, so it can
>>> be used
>>> + // with GetBitContext
>>> + sps = p + 2;
>>> + p += sps_nal->i_payload - 2;
>>> + *p++ = 1;
>>> + memcpy(p, pps_nal->p_payload + 2, pps_nal->i_payload - 2);
>>> + p += pps_nal->i_payload - 2;
>>> +
>>> + if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
>>> + GetBitContext gbc;
>>> + H264ParamSets ps = { 0 };
>>> +
>>> + init_get_bits8(&gbc, sps, sps_nal->i_payload - 4);
>>> + skip_bits(&gbc, 8);
>>> + ret = ff_h264_decode_seq_parameter_set(&gbc, avctx, &ps, 1);
>>
>> ff_h264_decode_seq_parameter_set() expects to read from a GetBitContext
>> whose buffer has already been stripped of 0x03 escape bytes. Your buffer
>> hasn't and therefore it is possible for this function to return an error
>> even when the input is fine.
>
> Why would a buffer created by passing annexb=0 have the escape bytes? Is
> it not specific to that encapsulation, to prevent parsing image data as
> a start code?
>
You seem to believe that just because the 0x03 are not really useful in
ISOBMFF, they are not used in ISOBMFF. This is just not true. The 0x03
are not specific to annex B (they are not even defined in annex B; they
are defined in the most basic syntax structure of H.264: nal_unit, see
7.3.1 of the spec).
(If it were otherwise, our annex b->isobmff code in lavf would need to
strip it and our isobmff->a
Re: [FFmpeg-devel] [PATCH] avformat/dvdvideodec: use correct format string for menu read error, fixes compiler warning
Marth64:
> Signed-off-by: Marth64
> ---
> libavformat/dvdvideodec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
> index a182f95097..0ae2110cd2 100644
> --- a/libavformat/dvdvideodec.c
> +++ b/libavformat/dvdvideodec.c
> @@ -423,7 +423,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext
> *s, DVDVideoPlaybackState
>
> blocks_read = DVDReadBlocks(state->vob_file, state->sector_offset, 1,
> read_buf);
> if (blocks_read != 1) {
> -av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
> blocks_read=%d\n",
> +av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
> blocks_read=%ld\n",
> state->sector_offset, blocks_read);
>
> return AVERROR_INVALIDDATA;
blocks_read is ssize_t and therefore the correct specifier is "%zd", but
unfortunately that is not supported by all implementations (see
SIZE_SPECIFIER in lavu/internal.h). Just use an int64_t instead.
- 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 v4] avcodec/mpeg12dec: extract only one type of CC substream
In MPEG-2 user data, there can be different types of Closed Captions
formats embedded (A53, SCTE-20, or DVD). The current behavior of the
CC extraction code in the MPEG-2 decoder is to not be aware of
multiple formats if multiple exist, therefore allowing one format
to overwrite the other during the extraction process since the CC
extraction shares one output buffer for the normalized bytes.
This causes sources that have two CC formats to produce flawed output.
There exist real-world samples which contain both A53 and SCTE-20 captions
in the same MPEG-2 stream, and that manifest this problem. Example of symptom:
THANK YOU (expected) --> THTHANANK K YOYOUU (actual)
The solution is to pick only the first CC substream observed with valid bytes,
and ignore the other types. Additionally, provide an option for users
to manually "force" a type in the event that this matters for a particular
source.
Signed-off-by: Marth64
---
libavcodec/mpeg12dec.c | 64 --
1 file changed, 61 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 3a2f17e508..4ad1eb6572 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -62,6 +62,13 @@
#define A53_MAX_CC_COUNT 2000
+enum Mpeg2ClosedCaptionsFormat {
+CC_FORMAT_AUTO,
+CC_FORMAT_A53_PART4,
+CC_FORMAT_SCTE20,
+CC_FORMAT_DVD
+};
+
typedef struct Mpeg1Context {
MpegEncContext mpeg_enc_ctx;
int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
@@ -70,6 +77,7 @@ typedef struct Mpeg1Context {
AVStereo3D stereo3d;
int has_stereo3d;
AVBufferRef *a53_buf_ref;
+enum Mpeg2ClosedCaptionsFormat cc_format;
uint8_t afd;
int has_afd;
int slice_count;
@@ -1903,12 +1911,27 @@ static int vcr2_init_sequence(AVCodecContext *avctx)
return 0;
}
+static void mpeg_set_cc_format(AVCodecContext *avctx, enum
Mpeg2ClosedCaptionsFormat format,
+ const char *label)
+{
+Mpeg1Context *s1 = avctx->priv_data;
+
+av_assert2(format != CC_FORMAT_AUTO);
+
+if (!s1->cc_format) {
+s1->cc_format = format;
+
+av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is %s format\n",
label);
+}
+}
+
static int mpeg_decode_a53_cc(AVCodecContext *avctx,
const uint8_t *p, int buf_size)
{
Mpeg1Context *s1 = avctx->priv_data;
-if (buf_size >= 6 &&
+if ((!s1->cc_format || s1->cc_format == CC_FORMAT_A53_PART4) &&
+buf_size >= 6 &&
p[0] == 'G' && p[1] == 'A' && p[2] == '9' && p[3] == '4' &&
p[4] == 3 && (p[5] & 0x40)) {
/* extract A53 Part 4 CC data */
@@ -1927,9 +1950,11 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
memcpy(s1->a53_buf_ref->data + old_size, p + 7, cc_count *
UINT64_C(3));
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+mpeg_set_cc_format(avctx, CC_FORMAT_A53_PART4, "A/53 Part 4");
}
return 1;
-} else if (buf_size >= 2 &&
+} else if ((!s1->cc_format || s1->cc_format == CC_FORMAT_SCTE20) &&
+ buf_size >= 2 &&
p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
/* extract SCTE-20 CC data */
GetBitContext gb;
@@ -1973,10 +1998,13 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
cap += 3;
}
}
+
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+mpeg_set_cc_format(avctx, CC_FORMAT_SCTE20, "SCTE-20");
}
return 1;
-} else if (buf_size >= 11 &&
+} else if ((!s1->cc_format || s1->cc_format == CC_FORMAT_DVD) &&
+ buf_size >= 11 &&
p[0] == 'C' && p[1] == 'C' && p[2] == 0x01 && p[3] == 0xf8) {
/* extract DVD CC data
*
@@ -2033,7 +2061,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
p += 6;
}
}
+
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+mpeg_set_cc_format(avctx, CC_FORMAT_DVD, "DVD");
}
return 1;
}
@@ -2598,11 +2628,39 @@ const FFCodec ff_mpeg1video_decoder = {
},
};
+#define M2V_OFFSET(x) offsetof(Mpeg1Context, x)
+#define M2V_PARAM AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+
+static const AVOption mpeg2video_options[] = {
+{ "cc_format", "extract a specific Closed Captions format",
+ M2V_OFFSET(cc_format), AV_OPT_TYPE_INT, { .i64 = CC_FORMAT_AUTO },
+CC_FORMAT_AUTO, CC_FORMAT_DVD, M2V_PARAM, .unit = "cc_format" },
+
+ { "auto", "pick first seen CC substream", 0, AV_OPT_TYPE_CONST,
+{ .i64 = CC_FORMAT_AUTO },.flags = M2V_PARAM, .unit
= "cc_format" },
+ { "a53","pick A/53 Part 4 CC substream", 0, AV_OPT_TYPE_CONST,
+{ .i64 = CC_FORMAT_A53_PART4 }, .flags = M2V_PARAM, .
Re: [FFmpeg-devel] [PATCH] avformat/dvdvideodec: use correct format string for menu read error, fixes compiler warning
v2 on the 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] configure: add threads dep for vulkan
Mar 12, 2024, 05:16 by ffm...@gyani.pro: > Fixes #10900 > --- > configure | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/configure b/configure > index 05f8283af9..e0b5bcf589 100755 > --- a/configure > +++ b/configure > @@ -3076,6 +3076,7 @@ nvdec_deps="ffnvcodec" > vaapi_x11_deps="xlib_x11" > videotoolbox_hwaccel_deps="videotoolbox pthreads" > videotoolbox_hwaccel_extralibs="-framework QuartzCore" > +vulkan_deps="threads" > vulkan_deps_any="libdl LoadLibrary" > > av1_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_AV1" > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avformat/dvdvideodec: use int64_t for menu blocks_read and fix format statement
Signed-off-by: Marth64
---
libavformat/dvdvideodec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index a182f95097..19efc068cb 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -392,7 +392,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
uint8_t *buf, int buf_size,
void (*flush_cb)(AVFormatContext *s))
{
-ssize_t blocks_read = 0;
+int64_t blocks_read = 0;
uint8_t read_buf[DVDVIDEO_BLOCK_SIZE] = {0};
pci_t pci = (pci_t) {0};
dsi_t dsi = (dsi_t) {0};
@@ -423,7 +423,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
blocks_read = DVDReadBlocks(state->vob_file, state->sector_offset, 1,
read_buf);
if (blocks_read != 1) {
-av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%d\n",
+av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%ld\n",
state->sector_offset, blocks_read);
return AVERROR_INVALIDDATA;
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/dvdvideodec: use int64_t for menu blocks_read and fix format statement
Marth64:
> Signed-off-by: Marth64
> ---
> libavformat/dvdvideodec.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
> index a182f95097..19efc068cb 100644
> --- a/libavformat/dvdvideodec.c
> +++ b/libavformat/dvdvideodec.c
> @@ -392,7 +392,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext
> *s, DVDVideoPlaybackState
> uint8_t *buf, int buf_size,
> void (*flush_cb)(AVFormatContext *s))
> {
> -ssize_t blocks_read = 0;
> +int64_t blocks_read = 0;
> uint8_t read_buf[DVDVIDEO_BLOCK_SIZE] = {0};
> pci_t pci = (pci_t) {0};
> dsi_t dsi = (dsi_t) {0};
> @@ -423,7 +423,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext
> *s, DVDVideoPlaybackState
>
> blocks_read = DVDReadBlocks(state->vob_file, state->sector_offset, 1,
> read_buf);
> if (blocks_read != 1) {
> -av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
> blocks_read=%d\n",
> +av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
> blocks_read=%ld\n",
> state->sector_offset, blocks_read);
>
> return AVERROR_INVALIDDATA;
ld is for long, not necessarily for int64_t.
- 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".
Re: [FFmpeg-devel] [PATCH v2] avformat/dvdvideodec: use int64_t for menu blocks_read and fix format statement
Fix on the way with PRId64 ___ 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] avformat/dvdvideodec: use int64_t for menu blocks_read and make format expressions portable
Signed-off-by: Marth64
---
libavformat/dvdvideodec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavformat/dvdvideodec.c b/libavformat/dvdvideodec.c
index a182f95097..761ac97ec6 100644
--- a/libavformat/dvdvideodec.c
+++ b/libavformat/dvdvideodec.c
@@ -392,7 +392,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
uint8_t *buf, int buf_size,
void (*flush_cb)(AVFormatContext *s))
{
-ssize_t blocks_read = 0;
+int64_t blocks_read = 0;
uint8_t read_buf[DVDVIDEO_BLOCK_SIZE] = {0};
pci_t pci = (pci_t) {0};
dsi_t dsi = (dsi_t) {0};
@@ -423,7 +423,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
blocks_read = DVDReadBlocks(state->vob_file, state->sector_offset, 1,
read_buf);
if (blocks_read != 1) {
-av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%d\n",
+av_log(s, AV_LOG_ERROR, "Unable to read VOB block: offset=%d
blocks_read=%" PRId64 "\n",
state->sector_offset, blocks_read);
return AVERROR_INVALIDDATA;
@@ -475,7 +475,7 @@ static int dvdvideo_menu_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
state->vobu_e_ptm= pci.pci_gi.vobu_e_ptm;
av_log(s, AV_LOG_DEBUG, "NAV packet: sector=%d "
-"vobu_s_ptm=%d vobu_e_ptm=%d ts_offset=%ld\n",
+"vobu_s_ptm=%d vobu_e_ptm=%d ts_offset=%"
PRId64 "\n",
dsi.dsi_gi.nv_pck_lbn,
pci.pci_gi.vobu_s_ptm, pci.pci_gi.vobu_e_ptm,
state->ts_offset);
@@ -758,7 +758,7 @@ static int dvdvideo_play_next_ps_block(AVFormatContext *s,
DVDVideoPlaybackState
av_log(s, AV_LOG_DEBUG,
"NAV packet: s_ptm=%d e_ptm=%d "
- "scr=%d lbn=%d vobu_duration=%d nav_pts=%ld\n",
+ "scr=%d lbn=%d vobu_duration=%d nav_pts=%" PRId64 "\n",
e_pci->pci_gi.vobu_s_ptm, e_pci->pci_gi.vobu_e_ptm,
e_dsi->dsi_gi.nv_pck_scr,
e_pci->pci_gi.nv_pck_lbn, state->vobu_duration,
state->nav_pts);
@@ -1639,18 +1639,19 @@ static int dvdvideo_read_packet(AVFormatContext *s,
AVPacket *pkt)
pkt->dts += c->play_state.ts_offset - c->first_pts;
if (pkt->pts < 0) {
-av_log(s, AV_LOG_VERBOSE, "Discarding packet with negative PTS
(st=%d pts=%ld), "
+av_log(s, AV_LOG_VERBOSE, "Discarding packet with negative PTS
(st=%d pts=%" PRId64 "), "
"this is OK at start of playback\n",
pkt->stream_index, pkt->pts);
return FFERROR_REDO;
}
} else {
-av_log(s, AV_LOG_WARNING, "Unset PTS or DTS @ st=%d pts=%ld dts=%ld\n",
+av_log(s, AV_LOG_WARNING, "Unset PTS or DTS @ st=%d pts=%" PRId64 "
dts=%" PRId64 "\n",
pkt->stream_index, pkt->pts, pkt->dts);
}
-av_log(s, AV_LOG_TRACE, "st=%d pts=%ld dts=%ld ts_offset=%ld
first_pts=%ld\n",
+av_log(s, AV_LOG_TRACE, "st=%d pts=%" PRId64 " dts=%" PRId64 " "
+"ts_offset=%" PRId64 " first_pts=%" PRId64 "\n",
pkt->stream_index, pkt->pts, pkt->dts,
c->play_state.ts_offset, c->first_pts);
--
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] avcodec/tiff: Use ff_tget_long() where appropriate
On date Tuesday 2024-03-12 15:49:45 +0100, Andreas Rheinhardt wrote: > No need to use the generic ff_tget() when we know the type. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/tiff.c | 36 ++-- > 1 file changed, 18 insertions(+), 18 deletions(-) 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 3/3] doc/muxers: add fifo_test
On date Tuesday 2024-03-12 13:25:23 +0100, Andreas Rheinhardt wrote: > Stefano Sabatini: > > --- > > doc/muxers.texi | 30 ++ > > 1 file changed, 30 insertions(+) > > [...] > I do not think that this muxer should be publically documented. In fact, > I think it would be better if this muxer would only exist inside the > fifo_muxer test and if it were not included in a normal libavformat at all. It looks like it is not possible to register a custom muxer outside of the list in allformats.c, or do I miss something? (OTOH it would be useful if one wants to registers a custom component, but this seems to be disabled at the API level). The simple alternative is to simply not to document the muxer, although I don't like it very much, given that is output in the muxers list, so I think at least we want to mention that this is only used for testing. ___ 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/muxers: add ffmetadata
On date Tuesday 2024-03-12 16:33:20 +0530, Gyan Doshi wrote:
> On 2024-03-12 04:25 pm, Stefano Sabatini wrote:
> > ---
> > doc/metadata.texi | 1 +
> > doc/muxers.texi | 16
> > 2 files changed, 17 insertions(+)
> >
Updated.
>From ce9846bc53c29ad2ff0331b5c90173120014843e Mon Sep 17 00:00:00 2001
From: Stefano Sabatini
Date: Sat, 20 Jan 2024 19:19:23 +0100
Subject: [PATCH] doc/muxers: add ffmetadata
---
doc/metadata.texi | 1 +
doc/muxers.texi | 17 +
2 files changed, 18 insertions(+)
diff --git a/doc/metadata.texi b/doc/metadata.texi
index be91059a98..e081da7735 100644
--- a/doc/metadata.texi
+++ b/doc/metadata.texi
@@ -1,3 +1,4 @@
+@anchor{metadata}
@chapter Metadata
@c man begin METADATA
diff --git a/doc/muxers.texi b/doc/muxers.texi
index a697e4b153..28db966c01 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1429,6 +1429,23 @@ Use @command{ffmpeg} to convert the input:
ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r 29.97 -ac 2 -ar 48000 -y out.dv
@end example
+@section ffmetadata
+FFmpeg metadata muxer.
+
+This muxer writes the streams metadata in the @samp{ffmetadata}
+format.
+
+See @ref{metadata,,the Metadata chapter,ffmpeg-formats} for
+information about the format.
+
+@subsection Example
+
+Use @command{ffmpeg} to extract metadata from an input file to a @file{metadata.ffmeta}
+file in @samp{ffmetadata} format:
+@example
+ffmpeg -i INPUT -f ffmetadata metadata.ffmeta
+@end example
+
@anchor{fifo}
@section fifo
FIFO (First-In First-Out) muxer.
--
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 v4] avcodec/mpeg12dec: extract only one type of CC substream
On date Tuesday 2024-03-12 10:43:11 -0500, Marth64 wrote: > In MPEG-2 user data, there can be different types of Closed Captions > formats embedded (A53, SCTE-20, or DVD). The current behavior of the > CC extraction code in the MPEG-2 decoder is to not be aware of > multiple formats if multiple exist, therefore allowing one format > to overwrite the other during the extraction process since the CC > extraction shares one output buffer for the normalized bytes. > > This causes sources that have two CC formats to produce flawed output. > There exist real-world samples which contain both A53 and SCTE-20 captions > in the same MPEG-2 stream, and that manifest this problem. Example of symptom: > THANK YOU (expected) --> THTHANANK K YOYOUU (actual) > > The solution is to pick only the first CC substream observed with valid bytes, > and ignore the other types. Additionally, provide an option for users > to manually "force" a type in the event that this matters for a particular > source. > > Signed-off-by: Marth64 > --- > libavcodec/mpeg12dec.c | 64 -- > 1 file changed, 61 insertions(+), 3 deletions(-) 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 v3] avformat/dvdvideodec: use int64_t for menu blocks_read and make format expressions portable
On date Tuesday 2024-03-12 11:14:09 -0500, Marth64 wrote: > Signed-off-by: Marth64 > --- > libavformat/dvdvideodec.c | 15 --- > 1 file changed, 8 insertions(+), 7 deletions(-) LGTM, thanks (will apply soon if there are no further comments). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
Hello, On Sat, Mar 9, 2024 at 8:25 PM Michael Niedermayer wrote: > Some members of the CC want to indefinitely ban Balling > from trac. And as our doc/community.texi says: > "Indefinite bans from the community must be confirmed by the General > Assembly, in a majority vote." > > Thus some CC member wishes to involve the public here > (really theres no other option, the GA cannot discuss/vote on what it > doesnt know) > > Also people have asked for more transparency and i strongly agree with > transparency. > For reference, Anton and I banned "balling" from IRC in November. We (FFmpeg's CC) have since then received a request to ban him from trac as well. The ban on IRC was following what happened in #ffmpeg-devel on 11/23/2023 ( https://libera.irclog.whitequark.org/ffmpeg-devel/2023-11-23) I've copied the logs from that link between 14:43 and 18:53 below here for reference. My nick is "BBB", and Anton's nick is "elenril". We also received help from jess, one of Libera's admins. 14:43 is Valerii Zapodovnikov the same person that was trolling here earlier? 14:44 yes 14:44 valzapod is his other nickname 14:57 okay so he's active in VLC and placebo too 14:57 yea 14:57 and many other projects which haven't banned him yet 15:56 and you will not be able to ban me 15:56 You want the Moscow trollfarm? 15:57 You will get it 15:57 Just do not forget I own copyright in ffmpeg too. 15:58 implying someone here asked for it. you're the one behaving how you are. maybe you feel you're completely OK, but alas that is not a view shared by many. maybe you're much better IRL, but no-one here has had the chance of experiencing that. 15:59 BTW, I really am surprised. I helped you trac progress as Balling and now that is what I get? LOL, maybe start with trac then, Biden libtard voters. Is the Russian collusion in the room with right now? 15:59 *with us 16:00 courmisch I am active also on wireshark, libtorrent 16:00 gnuradio (was), rtl-sdr project, all Intel libraries, clang now too. 16:01 Are you going and try to ban be there too? You will lose. Just like Biden lost the election, admit it 16:03 BTW, banning all VPNs is nice. Are you using same filter as wikipedia? Cool. But again, github servers do no use VPNs, they are real. And so are all different virtual machines. 16:03 Oh, and I web.archived that discussion on github 16:05 on vlc's gitlab, I mean 16:06 Biden lost the election, can you LOL??? 16:06 another maroon 16:07 JEEB: I am the same in real life, BTW. You just cannot ban a person in real life, only kill. Like that woman that said All lives matter in USA. 16:09 zadedfqul was kicked from #ffmpeg-devel by elenril [zadedfqul] 16:09 pls do NOT engage the troll 16:10 I blame TypX this time, but he did not "know" 16:13 Banning is also engaging, Anton 16:14 Just like your knowledge in top posting. 16:14 https://i.imgur.com/3tv4c5x.jpg 16:15 wsqacadq was kicked from #ffmpeg-devel by elenril [wsqacadq] 16:19 man that dude is persistent :) 16:19 does he not have something better to do with his life 16:19 takes commitment to contract a VPN just for trolling opensoars 16:20 or maybe it's provided for official Mordor public service use 16:20 :) 16:20 we'll keep banning the balling 16:20 every time I saw that, I hear the dwarfs from the hobbit 16:20 courmisch: to be honest the location from which a person is does not matter at all 16:21 s/is/comes/ 16:21 untrue 16:21 were he from a civilized country, we could use their law enforcement services 16:21 yea, but someone being an asshole or troll is not is a person problem 16:21 asdf 16:21 I was alluding to troll farms. Not every country has them, especially not on the scale of the Russian federation 16:21 *is* a person problem 16:22 obviously some devs over there are reasonable people 16:26 BTW, Trump just needed 44000 votes to win 16:27 i thought you said he won? be consistent 16:27 And so as there are up to a million ballot that were not observed he really did win. 16:27 ukrainesucks was banned on #ffmpeg-devel by BBB [*!~ ukrainesu@195.189.226.40] 16:27 ukrainesucks was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:27 psykose: i mean it 16:27 do NOT engage the troll 16:28 Also, Clinton was fined for Steele dossier 16:28 ukrainesuccxxks was banned on #ffmpeg-devel by BBB [*!~ ukrainesu@91.193.19.147] 16:28 ukrainesuccxxks was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:29 +r already 16:29 nah 16:29 I'm personally fine with +r 16:29 but if others object I won't insist on it 16:30 I don't think it's anywhere bad enough to require +r 16:30 (yet?) 16:30 Clinton was found to be using gmail 16:30 bsbsvsvsv was banned on #ffmpeg-devel by BBB [*!~ bsbsvsvsv@205.185.127.86] 16:30 bsbsvsvsv was kicked from #ffmpeg-devel by BBB [Your behavior is not conducive to the desired environment.] 16:30 dbbsbsbs was banned on #ffmpeg-devel by B
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Tue, Mar 12, 2024 at 6:15 PM Ronald S. Bultje wrote: > Hello, > > On Sat, Mar 9, 2024 at 8:25 PM Michael Niedermayer > > wrote: > > > Some members of the CC want to indefinitely ban Balling > > from trac. And as our doc/community.texi says: > > "Indefinite bans from the community must be confirmed by the General > > Assembly, in a majority vote." > > > > Thus some CC member wishes to involve the public here > > (really theres no other option, the GA cannot discuss/vote on what it > > doesnt know) > > > > Also people have asked for more transparency and i strongly agree with > > transparency. > > > > For reference, Anton and I banned "balling" from IRC in November. We > (FFmpeg's CC) have since then received a request to ban him from trac as > well. > > The ban on IRC was following what happened in #ffmpeg-devel on 11/23/2023 ( > https://libera.irclog.whitequark.org/ffmpeg-devel/2023-11-23) > I've copied the logs from that link between 14:43 and 18:53 below here for > reference. My nick is "BBB", and Anton's nick is "elenril". We also > received help from jess, one of Libera's admins. > > 14:43 is Valerii Zapodovnikov the same person that was trolling > here earlier? > 14:44 yes > 14:44 valzapod is his other nickname > 14:57 okay so he's active in VLC and placebo too > 14:57 yea > 14:57 and many other projects which haven't banned him yet > 15:56 and you will not be able to ban me > 15:56 You want the Moscow trollfarm? > 15:57 You will get it > 15:57 Just do not forget I own copyright in ffmpeg too. > 15:58 implying someone here asked for it. you're the one behaving > how you are. maybe you feel you're completely OK, but alas that is not a > view shared by many. maybe you're much better IRL, but no-one here has had > the chance of experiencing that. > 15:59 BTW, I really am surprised. I helped you trac progress as > Balling and now that is what I get? LOL, maybe start with trac then, Biden > libtard voters. Is the Russian collusion in the room with right now? > 15:59 *with us > 16:00 courmisch I am active also on wireshark, libtorrent > 16:00 gnuradio (was), rtl-sdr project, all Intel libraries, > clang now too. > 16:01 Are you going and try to ban be there too? You will lose. > Just like Biden lost the election, admit it > 16:03 BTW, banning all VPNs is nice. Are you using same filter > as wikipedia? Cool. But again, github servers do no use VPNs, they are > real. And so are all different virtual machines. > 16:03 Oh, and I web.archived that discussion on github > 16:05 on vlc's gitlab, I mean > 16:06 Biden lost the election, can you LOL??? > 16:06 another maroon > 16:07 JEEB: I am the same in real life, BTW. You just cannot > ban a person in real life, only kill. Like that woman that said All lives > matter in USA. > 16:09 zadedfqul was kicked from #ffmpeg-devel by elenril [zadedfqul] > 16:09 pls do NOT engage the troll > 16:10 I blame TypX this time, but he did not "know" > 16:13 Banning is also engaging, Anton > 16:14 Just like your knowledge in top posting. > 16:14 https://i.imgur.com/3tv4c5x.jpg > 16:15 wsqacadq was kicked from #ffmpeg-devel by elenril [wsqacadq] > 16:19 man that dude is persistent :) > 16:19 does he not have something better to do with his life > 16:19 takes commitment to contract a VPN just for trolling > opensoars > 16:20 or maybe it's provided for official Mordor public service > use > 16:20 :) > 16:20 we'll keep banning the balling > 16:20 every time I saw that, I hear the dwarfs from the hobbit > 16:20 courmisch: to be honest the location from which a person is > does not matter at all > 16:21 s/is/comes/ > 16:21 untrue > 16:21 were he from a civilized country, we could use their law > enforcement services > 16:21 yea, but someone being an asshole or troll is not is a person > problem > 16:21 asdf > 16:21 I was alluding to troll farms. Not every country has > them, especially not on the scale of the Russian federation > 16:21 *is* a person problem > 16:22 obviously some devs over there are reasonable people > 16:26 BTW, Trump just needed 44000 votes to win > 16:27 i thought you said he won? be consistent > 16:27 And so as there are up to a million ballot that were > not observed he really did win. > 16:27 ukrainesucks was banned on #ffmpeg-devel by BBB [*!~ > ukrainesu@195.189.226.40] > 16:27 ukrainesucks was kicked from #ffmpeg-devel by BBB [Your behavior is > not conducive to the desired environment.] > 16:27 psykose: i mean it > 16:27 do NOT engage the troll > 16:28 Also, Clinton was fined for Steele dossier > 16:28 ukrainesuccxxks was banned on #ffmpeg-devel by BBB [*!~ > ukrainesu@91.193.19.147] > 16:28 ukrainesuccxxks was kicked from #ffmpeg-devel by BBB [Your behavior > is not conducive to the desired environment.] > 16:29 +r already > 16:29 nah > 16:29 I'm personally fine with +r > 16:29 but if others object I won't insist on it > 16:30 I don't think it's anywhere bad enough to require +r > 16:30 (yet?) > 16:30
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
> > Dear LibAV core developer, thank you for this transcript. > If you feel like trolling, at least get your facts correct. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/fifo_test: Move into tests/fifo_muxer.c
This muxer solely exists to test the fifo muxer via a dedicated
test tool in libavformat/tests/fifo_muxer.c. It fulfills no
other role and it is only designed with this role in mind.
The latter can be seen in two facts: The muxer uses printf
for logging and it simply presumes the packets' data to contain
a FailingMuxerPacketData (a struct duplicated in fifo_test.c
and tests/fifo_muxer.c.); in particular, it presumes packets
to have data at all, but this need not be true with side-data
only packets and a segfault can easily be triggered by e.g.
encoding flac (our native encoder sends a side-data only packet
with updated extradata at the end of encoding).
This patch fixes this by moving the test muxer into the fifo
test tool, making it inaccessible via the API (and actually
removing it from libavformat.so and libavformat.a).
While this muxer was accessible via e.g. av_guess_format(),
it was not really usable for an API user as FailingMuxerPacketData
was not public. Therefore this is not considered a breaking change.
In order to continue to use the test muxer in the test tool,
the ordinary fifo muxer had to be overridden: fifo_muxer.c
includes lavf/fifo.c but with FIFO_TEST defined which makes
it support the fifo_test muxer. This is possible because
test tools are always linked statically to their respective
library.
Signed-off-by: Andreas Rheinhardt
---
Will I have to bump minor when applying this?
libavformat/Makefile | 1 -
libavformat/allformats.c | 1 -
libavformat/fifo.c | 7 ++
libavformat/fifo_test.c| 157 -
libavformat/tests/fifo_muxer.c | 126 +-
5 files changed, 132 insertions(+), 160 deletions(-)
delete mode 100644 libavformat/fifo_test.c
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 785349c036..94a949f555 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -205,7 +205,6 @@ OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o pcm.o
OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
OBJS-$(CONFIG_FFMETADATA_MUXER) += ffmetaenc.o
OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
-OBJS-$(CONFIG_FIFO_TEST_MUXER) += fifo_test.o
OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
OBJS-$(CONFIG_FILMSTRIP_MUXER) += filmstripenc.o rawenc.o
OBJS-$(CONFIG_FITS_DEMUXER) += fitsdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 5639715104..e15d0fa6d7 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -165,7 +165,6 @@ extern const FFOutputFormat ff_f4v_muxer;
extern const FFInputFormat ff_ffmetadata_demuxer;
extern const FFOutputFormat ff_ffmetadata_muxer;
extern const FFOutputFormat ff_fifo_muxer;
-extern const FFOutputFormat ff_fifo_test_muxer;
extern const FFInputFormat ff_filmstrip_demuxer;
extern const FFOutputFormat ff_filmstrip_muxer;
extern const FFInputFormat ff_fits_demuxer;
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index a3d41ba0d3..2a2673f4d8 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -528,6 +528,13 @@ static int fifo_init(AVFormatContext *avf)
atomic_init(&fifo->queue_duration, 0);
fifo->last_sent_dts = AV_NOPTS_VALUE;
+#ifdef FIFO_TEST
+/* This exists for the fifo_muxer test tool. */
+if (fifo->format && !strcmp(fifo->format, "fifo_test")) {
+extern const FFOutputFormat ff_fifo_test_muxer;
+oformat = &ff_fifo_test_muxer.p;
+} else
+#endif
oformat = av_guess_format(fifo->format, avf->url, NULL);
if (!oformat) {
ret = AVERROR_MUXER_NOT_FOUND;
diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
deleted file mode 100644
index 3861c4aee4..00
--- a/libavformat/fifo_test.c
+++ /dev/null
@@ -1,157 +0,0 @@
-/*
- * FIFO test pseudo-muxer
- * Copyright (c) 2016 Jan Sebechlebsky
- *
- * 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
-
-#include "libavutil/opt.h"
-#include "libavutil/time.h"
-
-#include "avformat.h"
-#include "mux.h"
-#include "url.h"
-
-/* Implementation of mock muxer to simulate real muxer failures */
-
-#define MAX_TST_PACKETS 128
-#define SLEEPTIME_50_MS 5
-#define SLEEPTIME_10_MS 1
-
-/* Implementation
[FFmpeg-devel] [PATCH 1/4] avcodec/av1dec: use named constants for ITU-T T.35 metadata
Signed-off-by: James Almer
---
libavcodec/av1dec.c | 12 +++-
libavcodec/itut35.h | 28
2 files changed, 35 insertions(+), 5 deletions(-)
create mode 100644 libavcodec/itut35.h
diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
index e6346b51db..4d074c3908 100644
--- a/libavcodec/av1dec.c
+++ b/libavcodec/av1dec.c
@@ -34,6 +34,7 @@
#include "decode.h"
#include "hwaccel_internal.h"
#include "internal.h"
+#include "itut35.h"
#include "hwconfig.h"
#include "profiles.h"
#include "refstruct.h"
@@ -951,7 +952,7 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
provider_code = bytestream2_get_be16(&gb);
switch (provider_code) {
-case 0x31: { // atsc_provider_code
+case ITU_T_T35_PROVIDER_CODE_ATSC: {
uint32_t user_identifier = bytestream2_get_be32(&gb);
switch (user_identifier) {
case MKBETAG('G', 'A', '9', '4'): { // closed captions
@@ -975,12 +976,12 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
}
break;
}
-case 0x3C: { // smpte_provider_code
+case ITU_T_T35_PROVIDER_CODE_SMTPE: {
AVDynamicHDRPlus *hdrplus;
int provider_oriented_code = bytestream2_get_be16(&gb);
int application_identifier = bytestream2_get_byte(&gb);
-if (itut_t35->itu_t_t35_country_code != 0xB5 ||
+if (itut_t35->itu_t_t35_country_code != ITU_T_T35_COUNTRY_CODE_US ||
provider_oriented_code != 1 || application_identifier != 4)
break;
@@ -994,9 +995,10 @@ static int export_itut_t35(AVCodecContext *avctx, AVFrame
*frame,
return ret;
break;
}
-case 0x3B: { // dolby_provider_code
+case ITU_T_T35_PROVIDER_CODE_DOLBY: {
int provider_oriented_code = bytestream2_get_be32(&gb);
-if (itut_t35->itu_t_t35_country_code != 0xB5 || provider_oriented_code
!= 0x800)
+if (itut_t35->itu_t_t35_country_code != ITU_T_T35_COUNTRY_CODE_US ||
+provider_oriented_code != 0x800)
break;
ret = ff_dovi_rpu_parse(&s->dovi, gb.buffer, gb.buffer_end -
gb.buffer);
diff --git a/libavcodec/itut35.h b/libavcodec/itut35.h
new file mode 100644
index 00..10063e6a9e
--- /dev/null
+++ b/libavcodec/itut35.h
@@ -0,0 +1,28 @@
+/*
+ * 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
+ */
+
+#ifndef AVCODEC_ITUT35_H
+#define AVCODEC_ITUT35_H
+
+#define ITU_T_T35_COUNTRY_CODE_US 0xB5
+
+#define ITU_T_T35_PROVIDER_CODE_ATSC 0x31
+#define ITU_T_T35_PROVIDER_CODE_DOLBY 0x3B
+#define ITU_T_T35_PROVIDER_CODE_SMTPE 0x3C
+
+#endif /* AVCODEC_ITUT35_H */
--
2.44.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 2/4] avcodec/h2645_sei: use named constants for ITU-T T.35 metadata
Signed-off-by: James Almer
---
libavcodec/h2645_sei.c | 10 ++
libavcodec/itut35.h| 2 ++
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/h2645_sei.c b/libavcodec/h2645_sei.c
index e60606f43f..e8eb15524f 100644
--- a/libavcodec/h2645_sei.c
+++ b/libavcodec/h2645_sei.c
@@ -40,6 +40,7 @@
#include "get_bits.h"
#include "golomb.h"
#include "h2645_sei.h"
+#include "itut35.h"
#define IS_H264(codec_id) (CONFIG_H264_SEI && CONFIG_HEVC_SEI ? codec_id ==
AV_CODEC_ID_H264 : CONFIG_H264_SEI)
#define IS_HEVC(codec_id) (CONFIG_H264_SEI && CONFIG_HEVC_SEI ? codec_id ==
AV_CODEC_ID_HEVC : CONFIG_HEVC_SEI)
@@ -140,7 +141,8 @@ static int decode_registered_user_data(H2645SEI *h,
GetByteContext *gb,
bytestream2_skipu(gb, 1); // itu_t_t35_country_code_extension_byte
}
-if (country_code != 0xB5 && country_code != 0x26) { // usa_country_code
and cn_country_code
+if (country_code != ITU_T_T35_COUNTRY_CODE_US &&
+country_code != ITU_T_T35_COUNTRY_CODE_CN) {
av_log(logctx, AV_LOG_VERBOSE,
"Unsupported User Data Registered ITU-T T35 SEI message
(country_code = %d)\n",
country_code);
@@ -151,7 +153,7 @@ static int decode_registered_user_data(H2645SEI *h,
GetByteContext *gb,
provider_code = bytestream2_get_be16u(gb);
switch (provider_code) {
-case 0x31: { // atsc_provider_code
+case ITU_T_T35_PROVIDER_CODE_ATSC: {
uint32_t user_identifier;
if (bytestream2_get_bytes_left(gb) < 4)
@@ -172,7 +174,7 @@ static int decode_registered_user_data(H2645SEI *h,
GetByteContext *gb,
break;
}
#if CONFIG_HEVC_SEI
-case 0x04: { // cuva_provider_code
+case ITU_T_T35_PROVIDER_CODE_CUVA: {
const uint16_t cuva_provider_oriented_code = 0x0005;
uint16_t provider_oriented_code;
@@ -188,7 +190,7 @@ static int decode_registered_user_data(H2645SEI *h,
GetByteContext *gb,
}
break;
}
-case 0x3C: { // smpte_provider_code
+case ITU_T_T35_PROVIDER_CODE_SMTPE: {
// A/341 Amendment - 2094-40
const uint16_t smpte2094_40_provider_oriented_code = 0x0001;
const uint8_t smpte2094_40_application_identifier = 0x04;
diff --git a/libavcodec/itut35.h b/libavcodec/itut35.h
index 10063e6a9e..ffa7024981 100644
--- a/libavcodec/itut35.h
+++ b/libavcodec/itut35.h
@@ -19,9 +19,11 @@
#ifndef AVCODEC_ITUT35_H
#define AVCODEC_ITUT35_H
+#define ITU_T_T35_COUNTRY_CODE_CN 0x26
#define ITU_T_T35_COUNTRY_CODE_US 0xB5
#define ITU_T_T35_PROVIDER_CODE_ATSC 0x31
+#define ITU_T_T35_PROVIDER_CODE_CUVA 0x04
#define ITU_T_T35_PROVIDER_CODE_DOLBY 0x3B
#define ITU_T_T35_PROVIDER_CODE_SMTPE 0x3C
--
2.44.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avcodec/libdav1d: use named constants for ITU-T T.35 metadata
Signed-off-by: James Almer
---
libavcodec/libdav1d.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index 1aa2d1f343..597944d88d 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -37,6 +37,7 @@
#include "decode.h"
#include "dovi_rpu.h"
#include "internal.h"
+#include "itut35.h"
#define FF_DAV1D_VERSION_AT_LEAST(x,y) \
(DAV1D_API_VERSION_MAJOR > (x) || DAV1D_API_VERSION_MAJOR == (x) &&
DAV1D_API_VERSION_MINOR >= (y))
@@ -542,7 +543,7 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
provider_code = bytestream2_get_be16(&gb);
switch (provider_code) {
-case 0x31: { // atsc_provider_code
+case ITU_T_T35_PROVIDER_CODE_ATSC: {
uint32_t user_identifier = bytestream2_get_be32(&gb);
switch (user_identifier) {
case MKBETAG('G', 'A', '9', '4'): { // closed captions
@@ -566,12 +567,12 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
}
break;
}
-case 0x3C: { // smpte_provider_code
+case ITU_T_T35_PROVIDER_CODE_SMTPE: {
AVDynamicHDRPlus *hdrplus;
int provider_oriented_code = bytestream2_get_be16(&gb);
int application_identifier = bytestream2_get_byte(&gb);
-if (itut_t35->country_code != 0xB5 ||
+if (itut_t35->country_code != ITU_T_T35_COUNTRY_CODE_US ||
provider_oriented_code != 1 || application_identifier != 4)
break;
@@ -587,9 +588,10 @@ static int libdav1d_receive_frame(AVCodecContext *c,
AVFrame *frame)
goto fail;
break;
}
-case 0x3B: { // dolby_provider_code
+case ITU_T_T35_PROVIDER_CODE_DOLBY: {
int provider_oriented_code = bytestream2_get_be32(&gb);
-if (itut_t35->country_code != 0xB5 || provider_oriented_code !=
0x800)
+if (itut_t35->country_code != ITU_T_T35_COUNTRY_CODE_US ||
+provider_oriented_code != 0x800)
break;
res = ff_dovi_rpu_parse(&dav1d->dovi, gb.buffer, gb.buffer_end -
gb.buffer);
--
2.44.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 4/4] avformat/matroska: use named constants for ITU-T T.35 metadata
Signed-off-by: James Almer --- libavformat/matroskadec.c | 4 +++- libavformat/matroskaenc.c | 5 +++-- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c index a35ca6ca5b..8897fd622c 100644 --- a/libavformat/matroskadec.c +++ b/libavformat/matroskadec.c @@ -54,6 +54,7 @@ #include "libavcodec/bytestream.h" #include "libavcodec/defs.h" #include "libavcodec/flac.h" +#include "libavcodec/itut35.h" #include "libavcodec/mpeg4audio.h" #include "libavcodec/packet_internal.h" @@ -3884,7 +3885,8 @@ static int matroska_parse_block_additional(MatroskaDemuxContext *matroska, country_code = bytestream2_get_byteu(&bc); provider_code = bytestream2_get_be16u(&bc); -if (country_code != 0xB5 || provider_code != 0x3C) +if (country_code != ITU_T_T35_COUNTRY_CODE_US || +provider_code != ITU_T_T35_PROVIDER_CODE_SMTPE) break; // ignore provider_oriented_code = bytestream2_get_be16u(&bc); diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 8ba0690f90..c2e172d5c0 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat/matroskaenc.c @@ -63,6 +63,7 @@ #include "libavcodec/codec_desc.h" #include "libavcodec/codec_par.h" #include "libavcodec/defs.h" +#include "libavcodec/itut35.h" #include "libavcodec/xiph.h" #include "libavcodec/mpeg4audio.h" @@ -2824,8 +2825,8 @@ static int mkv_write_block(void *logctx, MatroskaMuxContext *mkv, uint8_t *payload = t35_buf; size_t payload_size = sizeof(t35_buf) - 6; -bytestream_put_byte(&payload, 0xB5); // country_code -bytestream_put_be16(&payload, 0x3C); // provider_code +bytestream_put_byte(&payload, ITU_T_T35_COUNTRY_CODE_US); // country_code +bytestream_put_be16(&payload, ITU_T_T35_PROVIDER_CODE_SMTPE); // provider_code bytestream_put_be16(&payload, 0x01); // provider_oriented_code bytestream_put_byte(&payload, 0x04); // application_identifier -- 2.44.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 3/3] doc/muxers: add fifo_test
Stefano Sabatini: > On date Tuesday 2024-03-12 13:25:23 +0100, Andreas Rheinhardt wrote: >> Stefano Sabatini: >>> --- >>> doc/muxers.texi | 30 ++ >>> 1 file changed, 30 insertions(+) >>> > [...] >> I do not think that this muxer should be publically documented. In fact, >> I think it would be better if this muxer would only exist inside the >> fifo_muxer test and if it were not included in a normal libavformat at all. > > It looks like it is not possible to register a custom muxer outside of > the list in allformats.c, or do I miss something? (OTOH it would be > useful if one wants to registers a custom component, but this seems to > be disabled at the API level). > It is possible to use custom muxers internally: The AVOutputFormat* pointer one passes to avformat_alloc_output_context2() need not be in the list of output formats in the lists in allformats.c/alldevices.c. In order to make the fifo muxer actually use a custom muxer, a slight hack is needed. See https://ffmpeg.org/pipermail/ffmpeg-devel/2024-March/323314.html > The simple alternative is to simply not to document the muxer, > although I don't like it very much, given that is output in the muxers > list, so I think at least we want to mention that this is only used > for testing. Given that this muxer is dangerous (see the above commit message) it should not be publicly accessible at all. - 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".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Tue, Mar 12, 2024 at 7:11 PM Kieran Kunhya wrote: > > > > Dear LibAV core developer, thank you for this transcript. > > > > If you feel like trolling, at least get your facts correct. > Dear minor contributor, can you give link to fact checker to use? > > Kieran > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/fifo_test: Move into tests/fifo_muxer.c
On date Tuesday 2024-03-12 19:43:29 +0100, Andreas Rheinhardt wrote:
> This muxer solely exists to test the fifo muxer via a dedicated
> test tool in libavformat/tests/fifo_muxer.c. It fulfills no
> other role and it is only designed with this role in mind.
>
> The latter can be seen in two facts: The muxer uses printf
> for logging and it simply presumes the packets' data to contain
> a FailingMuxerPacketData (a struct duplicated in fifo_test.c
> and tests/fifo_muxer.c.); in particular, it presumes packets
> to have data at all, but this need not be true with side-data
> only packets and a segfault can easily be triggered by e.g.
> encoding flac (our native encoder sends a side-data only packet
> with updated extradata at the end of encoding).
>
> This patch fixes this by moving the test muxer into the fifo
> test tool, making it inaccessible via the API (and actually
> removing it from libavformat.so and libavformat.a).
> While this muxer was accessible via e.g. av_guess_format(),
> it was not really usable for an API user as FailingMuxerPacketData
> was not public. Therefore this is not considered a breaking change.
>
> In order to continue to use the test muxer in the test tool,
> the ordinary fifo muxer had to be overridden: fifo_muxer.c
> includes lavf/fifo.c but with FIFO_TEST defined which makes
> it support the fifo_test muxer. This is possible because
> test tools are always linked statically to their respective
> library.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Will I have to bump minor when applying this?
Given that this is a fix, probably a micro bump is enough.
>
> libavformat/Makefile | 1 -
> libavformat/allformats.c | 1 -
> libavformat/fifo.c | 7 ++
> libavformat/fifo_test.c| 157 -
> libavformat/tests/fifo_muxer.c | 126 +-
> 5 files changed, 132 insertions(+), 160 deletions(-)
> delete mode 100644 libavformat/fifo_test.c
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 785349c036..94a949f555 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -205,7 +205,6 @@ OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o
> pcm.o
> OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
> OBJS-$(CONFIG_FFMETADATA_MUXER) += ffmetaenc.o
> OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
> -OBJS-$(CONFIG_FIFO_TEST_MUXER) += fifo_test.o
> OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
> OBJS-$(CONFIG_FILMSTRIP_MUXER) += filmstripenc.o rawenc.o
> OBJS-$(CONFIG_FITS_DEMUXER) += fitsdec.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 5639715104..e15d0fa6d7 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -165,7 +165,6 @@ extern const FFOutputFormat ff_f4v_muxer;
> extern const FFInputFormat ff_ffmetadata_demuxer;
> extern const FFOutputFormat ff_ffmetadata_muxer;
> extern const FFOutputFormat ff_fifo_muxer;
> -extern const FFOutputFormat ff_fifo_test_muxer;
> extern const FFInputFormat ff_filmstrip_demuxer;
> extern const FFOutputFormat ff_filmstrip_muxer;
> extern const FFInputFormat ff_fits_demuxer;
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index a3d41ba0d3..2a2673f4d8 100644
> --- a/libavformat/fifo.c
> +++ b/libavformat/fifo.c
> @@ -528,6 +528,13 @@ static int fifo_init(AVFormatContext *avf)
> atomic_init(&fifo->queue_duration, 0);
> fifo->last_sent_dts = AV_NOPTS_VALUE;
>
> +#ifdef FIFO_TEST
> +/* This exists for the fifo_muxer test tool. */
> +if (fifo->format && !strcmp(fifo->format, "fifo_test")) {
> +extern const FFOutputFormat ff_fifo_test_muxer;
> +oformat = &ff_fifo_test_muxer.p;
> +} else
> +#endif
I see, but as unrelated note, it seems odd we don't have a register
API to add a custom muxer/demuxer, and having to go through this dance
is not really viable at the application level. That's why I wonder why
we don't have such API (I remember it was available at some point).
Anyway this hack is still better than keeping the fifo_test publicly
available.
> oformat = av_guess_format(fifo->format, avf->url, NULL);
> if (!oformat) {
> ret = AVERROR_MUXER_NOT_FOUND;
> diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
> deleted file mode 100644
> index 3861c4aee4..00
> --- a/libavformat/fifo_test.c
> +++ /dev/null
> @@ -1,157 +0,0 @@
> -/*
> - * FIFO test pseudo-muxer
> - * Copyright (c) 2016 Jan Sebechlebsky
> - *
> - * 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; withou
Re: [FFmpeg-devel] [PATCH] avformat/fifo_test: Move into tests/fifo_muxer.c
Stefano Sabatini:
> On date Tuesday 2024-03-12 19:43:29 +0100, Andreas Rheinhardt wrote:
>> This muxer solely exists to test the fifo muxer via a dedicated
>> test tool in libavformat/tests/fifo_muxer.c. It fulfills no
>> other role and it is only designed with this role in mind.
>>
>> The latter can be seen in two facts: The muxer uses printf
>> for logging and it simply presumes the packets' data to contain
>> a FailingMuxerPacketData (a struct duplicated in fifo_test.c
>> and tests/fifo_muxer.c.); in particular, it presumes packets
>> to have data at all, but this need not be true with side-data
>> only packets and a segfault can easily be triggered by e.g.
>> encoding flac (our native encoder sends a side-data only packet
>> with updated extradata at the end of encoding).
>>
>> This patch fixes this by moving the test muxer into the fifo
>> test tool, making it inaccessible via the API (and actually
>> removing it from libavformat.so and libavformat.a).
>> While this muxer was accessible via e.g. av_guess_format(),
>> it was not really usable for an API user as FailingMuxerPacketData
>> was not public. Therefore this is not considered a breaking change.
>>
>> In order to continue to use the test muxer in the test tool,
>> the ordinary fifo muxer had to be overridden: fifo_muxer.c
>> includes lavf/fifo.c but with FIFO_TEST defined which makes
>> it support the fifo_test muxer. This is possible because
>> test tools are always linked statically to their respective
>> library.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>
>> Will I have to bump minor when applying this?
>
> Given that this is a fix, probably a micro bump is enough.
>
>>
>> libavformat/Makefile | 1 -
>> libavformat/allformats.c | 1 -
>> libavformat/fifo.c | 7 ++
>> libavformat/fifo_test.c| 157 -
>> libavformat/tests/fifo_muxer.c | 126 +-
>> 5 files changed, 132 insertions(+), 160 deletions(-)
>> delete mode 100644 libavformat/fifo_test.c
>>
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index 785349c036..94a949f555 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -205,7 +205,6 @@ OBJS-$(CONFIG_EPAF_DEMUXER) += epafdec.o
>> pcm.o
>> OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
>> OBJS-$(CONFIG_FFMETADATA_MUXER) += ffmetaenc.o
>> OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
>> -OBJS-$(CONFIG_FIFO_TEST_MUXER) += fifo_test.o
>> OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
>> OBJS-$(CONFIG_FILMSTRIP_MUXER) += filmstripenc.o rawenc.o
>> OBJS-$(CONFIG_FITS_DEMUXER) += fitsdec.o
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 5639715104..e15d0fa6d7 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -165,7 +165,6 @@ extern const FFOutputFormat ff_f4v_muxer;
>> extern const FFInputFormat ff_ffmetadata_demuxer;
>> extern const FFOutputFormat ff_ffmetadata_muxer;
>> extern const FFOutputFormat ff_fifo_muxer;
>> -extern const FFOutputFormat ff_fifo_test_muxer;
>> extern const FFInputFormat ff_filmstrip_demuxer;
>> extern const FFOutputFormat ff_filmstrip_muxer;
>> extern const FFInputFormat ff_fits_demuxer;
>> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
>> index a3d41ba0d3..2a2673f4d8 100644
>> --- a/libavformat/fifo.c
>> +++ b/libavformat/fifo.c
>> @@ -528,6 +528,13 @@ static int fifo_init(AVFormatContext *avf)
>> atomic_init(&fifo->queue_duration, 0);
>> fifo->last_sent_dts = AV_NOPTS_VALUE;
>>
>
>> +#ifdef FIFO_TEST
>> +/* This exists for the fifo_muxer test tool. */
>> +if (fifo->format && !strcmp(fifo->format, "fifo_test")) {
>> +extern const FFOutputFormat ff_fifo_test_muxer;
>> +oformat = &ff_fifo_test_muxer.p;
>> +} else
>> +#endif
>
> I see, but as unrelated note, it seems odd we don't have a register
> API to add a custom muxer/demuxer, and having to go through this dance
> is not really viable at the application level. That's why I wonder why
> we don't have such API (I remember it was available at some point).
>
The reason is that this would complicate changing the internals of
(de)muxers.
> Anyway this hack is still better than keeping the fifo_test publicly
> available.
>
>> oformat = av_guess_format(fifo->format, avf->url, NULL);
>> if (!oformat) {
>> ret = AVERROR_MUXER_NOT_FOUND;
>> diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
>> deleted file mode 100644
>> index 3861c4aee4..00
>> --- a/libavformat/fifo_test.c
>> +++ /dev/null
>> @@ -1,157 +0,0 @@
>> -/*
>> - * FIFO test pseudo-muxer
>> - * Copyright (c) 2016 Jan Sebechlebsky
>> - *
>> - * 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 b
[FFmpeg-devel] [PATCH 1/2] doc/muxers: add film_cpk
---
doc/muxers.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 12bc433409..7f9ff9929f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1587,6 +1587,17 @@ ffmpeg -re -i ... -c:v libx264 -c:a aac -f fifo
-fifo_format fifo_test -format_o
-drop_pkts_on_overflow 1 -attempt_recovery 1 -recovery_wait_time 1 out.test
@end example
+@section film_cpk
+SEGA FILM (.cpk) muxer.
+
+This format was used as internal format for several SEGA games.
+
+For more information regarding the Sega FILM file format, visit
+@url{http://wiki.multimedia.cx/index.php?title=Sega_FILM}.
+
+It accepts at maximum one @samp{cinepak} or raw video stream, and maximum one
audio
+stream.
+
@section flv
Adobe Flash Video Format muxer.
--
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/2] doc/muxers: add filstrip
---
doc/muxers.texi | 6 ++
1 file changed, 6 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 7f9ff9929f..2c05b17f5e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1598,6 +1598,12 @@ For more information regarding the Sega FILM file
format, visit
It accepts at maximum one @samp{cinepak} or raw video stream, and maximum one
audio
stream.
+@section filmstrip
+Adobe Filmstrip muxer.
+
+This format is used by several Adobe tools to store a generated filmstrip
export. It
+accepts a single raw video stream.
+
@section flv
Adobe Flash Video Format muxer.
--
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] doc/muxers: add fits
---
doc/muxers.texi | 8
1 file changed, 8 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2c05b17f5e..de4b9b01f5 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1604,6 +1604,14 @@ Adobe Filmstrip muxer.
This format is used by several Adobe tools to store a generated filmstrip
export. It
accepts a single raw video stream.
+@section fits
+Flexible Image Transport System (FITS) muxer.
+
+This image format is used to store astronomical data.
+
+For more information regarding the format, visit
+@url{https://fits.gsfc.nasa.gov}.
+
@section flv
Adobe Flash Video Format muxer.
--
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] avformat/fifo_test: Move into tests/fifo_muxer.c
On date Tuesday 2024-03-12 21:25:31 +0100, Andreas Rheinhardt wrote: [...] > > nit: FifoTestMuxerPacketData > > > > This would necessitate changes to the part of the test tool that I did > not change and would therefore need to be a commit of its own. I can do > this, of course. Of course, feel free to ignore the nits and just push, we can followup later. ___ 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/muxers: add flac
---
doc/muxers.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index de4b9b01f5..64d9221198 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1612,6 +1612,17 @@ This image format is used to store astronomical data.
For more information regarding the format, visit
@url{https://fits.gsfc.nasa.gov}.
+@section flac
+Raw FLAC audio muxer.
+
+This muxer accepts exactly one FLAC audio stream. Additionally, it is possible
to add a
+single 32x32 PNG image as attached picture.
+
+@table @option
+@item write_header @var{bool}
+write the file header if set to @code{true}, default is @code{true}
+@end table
+
@section flv
Adobe Flash Video Format muxer.
--
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] doc/muxers: add flac
LGTM
On Tue, Mar 12, 2024 at 4:01 PM Stefano Sabatini wrote:
> ---
> doc/muxers.texi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index de4b9b01f5..64d9221198 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1612,6 +1612,17 @@ This image format is used to store astronomical
> data.
> For more information regarding the format, visit
> @url{https://fits.gsfc.nasa.gov}.
>
> +@section flac
> +Raw FLAC audio muxer.
> +
> +This muxer accepts exactly one FLAC audio stream. Additionally, it is
> possible to add a
> +single 32x32 PNG image as attached picture.
> +
> +@table @option
> +@item write_header @var{bool}
> +write the file header if set to @code{true}, default is @code{true}
> +@end table
> +
> @section flv
>
> Adobe Flash Video Format muxer.
> --
> 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 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 v8 06/14] avutil/frame: add helper for adding existing side data to array
On 3/11/2024 5:58 PM, Jan Ekström wrote:
---
libavutil/frame.c | 49 +++
libavutil/frame.h | 20 +++
2 files changed, 69 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 4074391a92..46f976a3ed 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -98,6 +98,23 @@ static void remove_side_data(AVFrameSideData ***sd, int
*nb_side_data,
}
}
+static void remove_side_data_by_entry(AVFrameSideData ***sd, int *nb_sd,
+ const AVFrameSideData *target)
+{
+for (int i = *nb_sd - 1; i >= 0; i--) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry != target)
+continue;
+
+free_side_data(&entry);
+
+((*sd)[i]) = ((*sd)[*nb_sd - 1]);
+(*nb_sd)--;
+
+return;
+}
+}
+
AVFrame *av_frame_alloc(void)
{
AVFrame *frame = av_malloc(sizeof(*frame));
@@ -764,6 +781,38 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
return ret;
}
+int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
+ const AVFrameSideData *src, unsigned int flags)
+{
+AVBufferRef *buf= NULL;
+AVFrameSideData *sd_dst = NULL;
+int ret= AVERROR_BUG;
+
+if (!sd || !src || !nb_sd || (*nb_sd && !*sd))
+return AVERROR(EINVAL);
+
+buf = av_buffer_ref(src->buf);
+if (!buf)
+return AVERROR(ENOMEM);
+
+if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
+remove_side_data(sd, nb_sd, src->type);
+
+sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, src->type, buf);
+if (!sd_dst) {
+av_buffer_unref(&buf);
+return AVERROR(ENOMEM);
+}
+
+ret = av_dict_copy(&sd_dst->metadata, src->metadata, 0);
+if (ret < 0) {
+remove_side_data_by_entry(sd, nb_sd, sd_dst);
+return ret;
+}
+
+return 0;
+}
+
AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
enum AVFrameSideDataType type)
{
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 5d68d1e7af..ce93421d60 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1021,6 +1021,26 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
enum AVFrameSideDataType type,
size_t size, unsigned int flags);
+/**
+ * Add a new side data entry to an array based on existing side data, taking
+ * a reference towards the contained AVBufferRef.
+ *
+ * @param sdpointer to array of side data to which to add another entry,
+ * or to NULL in order to start a new array.
+ * @param nb_sd pointer to an integer containing the number of entries in
+ * the array.
+ * @param src side data to be cloned, with a new reference utilized
+ * for the buffer.
+ * @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
+ *
+ * @return negative error code on failure, >=0 on success. In case of
+ * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
+ * AVFrameSideDataType will be removed before the addition is
+ * attempted.
+ */
+int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
+ const AVFrameSideData *src, unsigned int flags);
+
/**
* @}
*/
Patches 1 to 6 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 1/2] doc/muxers: add film_cpk
> SEGA FILM (.cpk) muxer. > This format was used as internal format for several SEGA games. > For more information regarding the Sega FILM file format (trivial nit) Sega should be capitalized SEGA I believe, this would make it consistent in all 3 lines. But it's still fine. 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 v8 07/14] avutil/frame: add helper for adding side data w/ AVBufferRef to array
On 3/11/2024 5:58 PM, Jan Ekström wrote:
This was requested to be added in review.
---
libavutil/frame.c | 43 ++-
libavutil/frame.h | 21 +
2 files changed, 51 insertions(+), 13 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 46f976a3ed..30db83a5e5 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -781,29 +781,46 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
return ret;
}
-int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
- const AVFrameSideData *src, unsigned int flags)
+AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+const AVBufferRef *buf,
+unsigned int flags)
{
-AVBufferRef *buf= NULL;
-AVFrameSideData *sd_dst = NULL;
-int ret= AVERROR_BUG;
+AVBufferRef *new_buf = NULL;
+AVFrameSideData *sd_dst = NULL;
-if (!sd || !src || !nb_sd || (*nb_sd && !*sd))
-return AVERROR(EINVAL);
+if (!sd || !buf || !nb_sd || (*nb_sd && !*sd))
+return NULL;
-buf = av_buffer_ref(src->buf);
+new_buf = av_buffer_ref(buf);
if (!buf)
-return AVERROR(ENOMEM);
+return NULL;
if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
-remove_side_data(sd, nb_sd, src->type);
+remove_side_data(sd, nb_sd, type);
-sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, src->type, buf);
+sd_dst = add_side_data_to_set_from_buf(sd, nb_sd, type, new_buf);
if (!sd_dst) {
-av_buffer_unref(&buf);
-return AVERROR(ENOMEM);
+av_buffer_unref(&new_buf);
+return NULL;
}
+return sd_dst;
+}
+
+int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
+ const AVFrameSideData *src, unsigned int flags)
+{
+AVFrameSideData *sd_dst = NULL;
+int ret= AVERROR_BUG;
+
+if (!src)
+return AVERROR(EINVAL);
+
+sd_dst = av_frame_side_data_add(sd, nb_sd, src->type, src->buf, flags);
+if (!sd_dst)
+return AVERROR(ENOMEM);
+
ret = av_dict_copy(&sd_dst->metadata, src->metadata, 0);
if (ret < 0) {
remove_side_data_by_entry(sd, nb_sd, sd_dst);
diff --git a/libavutil/frame.h b/libavutil/frame.h
index ce93421d60..a7e62ded15 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1021,6 +1021,27 @@ AVFrameSideData *av_frame_side_data_new(AVFrameSideData
***sd, int *nb_sd,
enum AVFrameSideDataType type,
size_t size, unsigned int flags);
+/**
+ * Add a new side data entry to an array from an existing AVBufferRef.
+ *
+ * @param sdpointer to array of side data to which to add another entry,
+ * or to NULL in order to start a new array.
+ * @param nb_sd pointer to an integer containing the number of entries in
+ * the array.
+ * @param type type of the added side data
+ * @param buf AVBufferRef for which a new reference will be made
+ * @param flags Some combination of AV_FRAME_SIDE_DATA_FLAG_* flags, or 0.
+ *
+ * @return newly added side data on success, NULL on error. In case of
+ * AV_FRAME_SIDE_DATA_FLAG_UNIQUE being set, entries of matching
+ * AVFrameSideDataType will be removed before the addition is
+ * attempted.
+ */
+AVFrameSideData *av_frame_side_data_add(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+const AVBufferRef *buf,
+unsigned int flags);
+
/**
* Add a new side data entry to an array based on existing side data, taking
* a reference towards the contained AVBufferRef.
This also LGTM, but Anton has expressed a dislike for the function
signature, preferring instead one that takes ownership of the buffer by
taking a pointer to pointer, and clearing it on success.
The argument was that the user may not care about keeping a reference to
the buffer after it's added to the side data array, but seeing how the
very first user in this patch does, I personally think this more
appropriate.
If others agree with him then I'll not oppose to it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] doc/muxers: add flac
Stefano Sabatini:
> ---
> doc/muxers.texi | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index de4b9b01f5..64d9221198 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1612,6 +1612,17 @@ This image format is used to store astronomical data.
> For more information regarding the format, visit
> @url{https://fits.gsfc.nasa.gov}.
>
> +@section flac
> +Raw FLAC audio muxer.
> +
> +This muxer accepts exactly one FLAC audio stream. Additionally, it is
> possible to add a
> +single 32x32 PNG image as attached picture.
This is wrong: Way more attached pictures are supported. The restriction
you are referring to only applies to pictures of type "32x32 pixels
'file icon'".
> +
> +@table @option
> +@item write_header @var{bool}
> +write the file header if set to @code{true}, default is @code{true}
> +@end table
> +
> @section flv
>
> Adobe Flash Video Format muxer.
___
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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
I have not interacted with this user and I am just a mediocre contributor. But from my experience running forums and IRC networks in the past, this always ends in one process... 1. toxic user comes along 2. upsets people repeatedly, which also wastes time 3. admins ponder ban, which wastes time 4. they get banned anyway 5. repeat for the next toxic user that comes along imo you have the right to /mode +b toxic_user!*@* ___ 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] change av_ts_make_time_string precision
On Tue, 12 Mar 2024, Allan Cady via ffmpeg-devel wrote:
On Monday, March 11, 2024 at 12:11:45 PM PDT, Marton Balint wrote:
On Mon, 11 Mar 2024, Andreas Rheinhardt wrote:
Allan Cady via ffmpeg-devel:
From: "Allan Cady"
I propose changing the format to "%.6f", which will
give microsecond precision for all timestamps, regardless of
offset. Trailing zeros can be trimmed from the fraction, without
losing precision. If the length of the fixed-precision formatted
timestamp exceeds the length of the allocated buffer
(AV_TS_MAX_STRING_SIZE, currently 32, less one for the
terminating null), then we can fall back to scientific notation, though
this seems almost certain to never occur, because 32 characters would
allow a maximum timestamp value of (32 - 1 - 6 - 1) = 24 characters.
By my calculation, 10^24 seconds is about six orders of magnitude
greater than the age of the universe.
The fix proposed here follows the following logic:
1) Try formatting the number of seconds using "%.6f". This will
always result in a string with six decimal digits in the fraction,
possibly including trailing zeros. (e.g. "897234.73200").
2) Check if that string would overflow the buffer. If it would, then
format it using scientific notation ("%.8g").
3) If the original fixed-point format fits, then trim any trailing
zeros and decimal point, and return that result.
Making this change broke two fate tests, filter-metadata-scdet,
and filter-metadata-silencedetect. To correct this, I've modified
tests/ref/fate/filter-metadata-scdet and
tests/ref/fate/filter-metadata-silencedetect to match the
new output.
Signed-off-by: Allan Cady
---
libavutil/timestamp.h | 53 +++-
tests/ref/fate/filter-metadata-scdet | 12 ++---
tests/ref/fate/filter-metadata-silencedetect | 2 +-
3 files changed, 58 insertions(+), 9 deletions(-)
diff --git a/libavutil/timestamp.h b/libavutil/timestamp.h
index 2b37781eba..2f04f9bb2b 100644
--- a/libavutil/timestamp.h
+++ b/libavutil/timestamp.h
@@ -25,6 +25,7 @@
#define AVUTIL_TIMESTAMP_H
#include "avutil.h"
+#include
#if defined(__cplusplus) && !defined(__STDC_FORMAT_MACROS) && !defined(PRId64)
#error missing -D__STDC_FORMAT_MACROS / #define __STDC_FORMAT_MACROS
@@ -53,6 +54,32 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
*/
#define av_ts2str(ts) av_ts_make_string((char[AV_TS_MAX_STRING_SIZE]){0}, ts)
+/**
+ * Strip trailing zeros and decimal point from a string. Performed
+ * in-place on input buffer. For local use only by av_ts_make_time_string.
+ *
+ * e.g.:
+ * "752.378000" -> "752.378"
+ * "4.0" -> "4"
+ * "97300" -> "97300"
+ */
+static inline void av_ts_strip_trailing_zeros_and_decimal_point(char *str) {
+ if (strchr(str, '.'))
+ {
+ int i;
+ for (i = strlen(str) - 1; i >= 0 && str[i] == '0'; i--) {
+ str[i] = '\0';
+ }
+
+ // Remove decimal point if it's the last character
+ if (i >= 0 && str[i] == '.') {
+ str[i] = '\0';
+ }
+
+ // String was modified in place; no need for return value.
+ }
+}
+
/**
* Fill the provided buffer with a string containing a timestamp time
* representation.
@@ -65,8 +92,30 @@ static inline char *av_ts_make_string(char *buf, int64_t ts)
static inline char *av_ts_make_time_string(char *buf, int64_t ts,
const AVRational *tb)
{
- if (ts == AV_NOPTS_VALUE) snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
- else snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.6g",
av_q2d(*tb) * ts);
+ if (ts == AV_NOPTS_VALUE)
+ {
+ snprintf(buf, AV_TS_MAX_STRING_SIZE, "NOPTS");
+ }
+ else
+ {
+ const int max_fraction_digits = 6;
+
+ // Convert 64-bit timestamp to double, using rational timebase
+ double seconds = av_q2d(*tb) * ts;
+
+ int length = snprintf(NULL, 0, "%.*f", max_fraction_digits, seconds);
+ if (length <= AV_TS_MAX_STRING_SIZE - 1)
+ {
+ snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.*f", max_fraction_digits,
seconds);
+ av_ts_strip_trailing_zeros_and_decimal_point(buf);
+ }
+ else
+ {
+ snprintf(buf, AV_TS_MAX_STRING_SIZE, "%.8g", seconds);
+ }
+
+ }
+
return buf;
}
1. What makes you believe that all users want the new format and that it
does not cause undesired behaviour for some (maybe a lot) of them? The
number of characters written by the earlier code stayed pretty constant
even when the times became big (in this case, it just printed 8 chars if
ts>=0), yet your code will really make use of the whole buffer.
Granted, we could tell our users that they have no right to complain
about this, given that we always had a "right" to use the full buffer,
but I consider this a violation of the principle of least surprise. Why
don't you just change silencedetect or add another function?
I suggested to ch
Re: [FFmpeg-devel] [PATCH v8 08/14] avutil/frame: add helper for getting side data from array
On 3/11/2024 5:58 PM, Jan Ekström wrote:
---
libavutil/frame.c | 20 +++-
libavutil/frame.h | 14 ++
2 files changed, 29 insertions(+), 5 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 30db83a5e5..47ecd964b8 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -830,16 +830,26 @@ int av_frame_side_data_clone(AVFrameSideData ***sd, int
*nb_sd,
return 0;
}
-AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
-enum AVFrameSideDataType type)
+const AVFrameSideData *av_frame_side_data_get(const AVFrameSideData **sd,
+ const int nb_sd,
+ enum AVFrameSideDataType type)
{
-for (int i = 0; i < frame->nb_side_data; i++) {
-if (frame->side_data[i]->type == type)
-return frame->side_data[i];
+for (int i = 0; i < nb_sd; i++) {
+if (sd[i]->type == type)
+return sd[i];
}
return NULL;
}
+AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
+enum AVFrameSideDataType type)
+{
+return (AVFrameSideData *)av_frame_side_data_get(
+(const AVFrameSideData **)frame->side_data, frame->nb_side_data,
+type
+);
+}
+
static int frame_copy_video(AVFrame *dst, const AVFrame *src)
{
int planes;
diff --git a/libavutil/frame.h b/libavutil/frame.h
index a7e62ded15..e59f033cce 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1062,6 +1062,20 @@ AVFrameSideData *av_frame_side_data_add(AVFrameSideData
***sd, int *nb_sd,
int av_frame_side_data_clone(AVFrameSideData ***sd, int *nb_sd,
const AVFrameSideData *src, unsigned int flags);
+/**
+ * Get a side data entry of a specific type from an array.
+ *
+ * @param sdarray of side data.
+ * @param nb_sd integer containing the number of entries in the array.
+ * @param type type of side data to be queried
+ *
+ * @return a pointer to the side data of a given type on success, NULL if there
+ * is no side data with such type in this set.
+ */
+const AVFrameSideData *av_frame_side_data_get(const AVFrameSideData **sd,
+ const int nb_sd,
+ enum AVFrameSideDataType type);
+
/**
* @}
*/
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 v8 09/14] avcodec: add frame side data array to AVCodecContext
On 3/11/2024 5:58 PM, Jan Ekström wrote:
This allows configuring an encoder by using AVFrameSideData.
---
libavcodec/avcodec.h | 8
libavcodec/options.c | 2 ++
2 files changed, 10 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 21fc74707f..432a3fd153 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2062,6 +2062,14 @@ typedef struct AVCodecContext {
* Number of entries in side_data_prefer_packet.
*/
unsigned nb_side_data_prefer_packet;
+
+/**
+ * Set containing static side data, such as HDR10 CLL / MDCV structures.
+ * - encoding: set by user
+ * - decoding: unused
This is not taking into account the requests from the last review round.
+ */
+AVFrameSideData **frame_side_data;
+int nb_frame_side_data;
} AVCodecContext;
/**
diff --git a/libavcodec/options.c b/libavcodec/options.c
index dcc67e497a..29b961411e 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -176,6 +176,8 @@ void avcodec_free_context(AVCodecContext **pavctx)
av_freep(&avctx->inter_matrix);
av_freep(&avctx->rc_override);
av_channel_layout_uninit(&avctx->ch_layout);
+av_frame_side_data_free(
+&avctx->frame_side_data, &avctx->nb_frame_side_data);
av_freep(pavctx);
}
___
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 7/9] avformat/pcm: factorize and improve determining the default packet size
On Fri, 8 Mar 2024, Marton Balint wrote: - Remove the 1024 cap on the number of samples, for high sample rate audio it was suboptimal, calculate the low neighbour power of two for the number of samples (audio blocks) instead. - Make the function work correctly for non-pcm codecs by using av_get_audio_frame_duration2() to esimate the packet duration for a given size - Fall back to 4096/block_align if av_get_audio_frame_duration2() is not supported Will apply this series soon. 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".
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/aom_film_grain: add AOM film grain synthesis
On Mon, 11 Mar 2024 22:32:01 + Mark Thompson wrote: > This is not correct. Along with scalable cases, the multiple param sets are > to support applying film grain at the display resolution after scaling, > providing a better result than upscaling the grain applied at the decode > resolution. > > For example, you could have a scalable stream with operating points of > 1920x1080, 1280x720 and 640x360. The AFGS1 metadata associated with the > stream would then have film grain parameters for those three resolutions, > plus perhaps 2560x1440 and 3840x2160. > > In the ideal case you then pick the operating point for decode based on your > available bandwidth and decode capabilities, and the resolution for film > grain application based on the display. The decode happens without any film > grain, the clean video is upscaled, and then the film grain is applied > immediately before display. > > A current conforming AV1 implementation which only supports applying film > grain as part of the decode process can do so and produce a conforming > result, but the quality may not be as good as the ideal case because the > presence of noise will affect the upscale quality and also the grain itself > will be scaled in a way which may not look correct. > > I'm not sure what the best way to expose this is. For a player application > an option to select the intended display resolution and then export an AV1 > film grain side data as it is now is sufficient, but that doesn't really work > in an application like ffmpeg where the target resolution isn't directly > known. One way to get there would be to attach multiple AVFilmGrainAOMParams structs as side data to the frame, plus adding the extra metadata for the resolution (and colorimetry etc.) to that struct. May be a bit awkward to deal with on the user side, though. > (Also note that a transcode can carry the AFGS1 message from the source to > the output without ever touching it, as long as the target resolution > satisfies the requirement on the coded resolution being available in the > param sets. It seems desirable to support this possibility.) > > Thanks, > > - Mark > ___ > 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/webvttdec: Skip more parts of header to let parsing continue
On Mon, 11 Mar 2024, Kristoffer Brånemyr via ffmpeg-devel wrote: Den måndag 26 februari 2024 kl. 19:36:58 CET, Kristoffer Brånemyr via ffmpeg-devel skrev: Hi, Here is a short patch to skip more parts of the header for the WebVTT subtitle format. Without this the parser seems to stop and no subtitles are produced for the user.You can find the WebVTT specification here: WebVTT: The Web Video Text Tracks Format WebVTT: The Web Video Text Tracks Format> >| >| >| I attach an example file using the STYLE header part. I verified that with this change, I can see the subtitles using mpv. I tried to run fate, but even without my changes it seems to fail? Hi again, Did anyone get a chance to look at this patch? It's a small patch, only adding two lines. Looks like the URL to the WebVTT specification got broken last time by the webmail I use, I hope this time it will work better: https://www.w3.org/TR/webvtt1/#file-structure Will apply. 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] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On Tue, Mar 12, 2024 at 5:20 PM Marth64 wrote: > I have not interacted with this user and I am just a mediocre contributor. > But from my experience running forums and IRC networks in the past, > this always ends in one process... > >1. toxic user comes along >2. upsets people repeatedly, which also wastes time >3. admins ponder ban, which wastes time >4. they get banned anyway >5. repeat for the next toxic user that comes along > > imo you have the right to /mode +b toxic_user!*@* > looking at the silver lining, at least people get banned on irc -- Vittorio ___ 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/hevc_cabac: Let compiler count offsets
Andreas Rheinhardt:
> This is easily possible with an X macro.
> Using an enum for the offsets also allows to remove
> two arrays which are not really needed and will typically
> be optimized away by the compiler: The first just exists
> to count the number of syntax elements*, the second one
> exists to get offset[CONSTANT]. These constants were
> of type enum SyntaxElement and this enum was only used
> in hevc_cabac.c (although it was declared in hevcdec.h);
> it is now no longer needed at all and has therefore been
> removed.
>
> The first of these arrays led to a warning from Clang
> which is fixed by this commit:
> warning: variable 'num_bins_in_se' is not needed and will
> not be emitted [-Wunneeded-internal-declaration]
>
> *: One could also just added a trailing SYNTAX_ELEMENT_NB
> to the SyntaxElement enum for this purpose.
>
> Signed-off-by: Andreas Rheinhardt
> ---
Will apply this patch tomorrow unless there are objections.
> libavcodec/hevc_cabac.c | 248
> libavcodec/hevcdec.h| 52 -
> 2 files changed, 100 insertions(+), 200 deletions(-)
>
> diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
> index 6b38da84bd..63ffb3d37c 100644
> --- a/libavcodec/hevc_cabac.c
> +++ b/libavcodec/hevc_cabac.c
> @@ -31,114 +31,66 @@
>
> #define CABAC_MAX_BIN 31
>
> -/**
> - * number of bin by SyntaxElement.
> - */
> -static const int8_t num_bins_in_se[] = {
> - 1, // sao_merge_flag
> - 1, // sao_type_idx
> - 0, // sao_eo_class
> - 0, // sao_band_position
> - 0, // sao_offset_abs
> - 0, // sao_offset_sign
> - 0, // end_of_slice_flag
> - 3, // split_coding_unit_flag
> - 1, // cu_transquant_bypass_flag
> - 3, // skip_flag
> - 3, // cu_qp_delta
> - 1, // pred_mode
> - 4, // part_mode
> - 0, // pcm_flag
> - 1, // prev_intra_luma_pred_mode
> - 0, // mpm_idx
> - 0, // rem_intra_luma_pred_mode
> - 2, // intra_chroma_pred_mode
> - 1, // merge_flag
> - 1, // merge_idx
> - 5, // inter_pred_idc
> - 2, // ref_idx_l0
> - 2, // ref_idx_l1
> - 2, // abs_mvd_greater0_flag
> - 2, // abs_mvd_greater1_flag
> - 0, // abs_mvd_minus2
> - 0, // mvd_sign_flag
> - 1, // mvp_lx_flag
> - 1, // no_residual_data_flag
> - 3, // split_transform_flag
> - 2, // cbf_luma
> - 5, // cbf_cb, cbf_cr
> - 2, // transform_skip_flag[][]
> - 2, // explicit_rdpcm_flag[][]
> - 2, // explicit_rdpcm_dir_flag[][]
> -18, // last_significant_coeff_x_prefix
> -18, // last_significant_coeff_y_prefix
> - 0, // last_significant_coeff_x_suffix
> - 0, // last_significant_coeff_y_suffix
> - 4, // significant_coeff_group_flag
> -44, // significant_coeff_flag
> -24, // coeff_abs_level_greater1_flag
> - 6, // coeff_abs_level_greater2_flag
> - 0, // coeff_abs_level_remaining
> - 0, // coeff_sign_flag
> - 8, // log2_res_scale_abs
> - 2, // res_scale_sign_flag
> - 1, // cu_chroma_qp_offset_flag
> - 1, // cu_chroma_qp_offset_idx
> -};
> +// ELEM(NAME, NUM_BINS)
> +#define CABAC_ELEMS(ELEM) \
> +ELEM(SAO_MERGE_FLAG, 1) \
> +ELEM(SAO_TYPE_IDX, 1) \
> +ELEM(SAO_EO_CLASS, 0) \
> +ELEM(SAO_BAND_POSITION, 0)\
> +ELEM(SAO_OFFSET_ABS, 0) \
> +ELEM(SAO_OFFSET_SIGN, 0) \
> +ELEM(END_OF_SLICE_FLAG, 0)\
> +ELEM(SPLIT_CODING_UNIT_FLAG, 3) \
> +ELEM(CU_TRANSQUANT_BYPASS_FLAG, 1)\
> +ELEM(SKIP_FLAG, 3)\
> +ELEM(CU_QP_DELTA, 3) \
> +ELEM(PRED_MODE_FLAG, 1) \
> +ELEM(PART_MODE, 4)\
> +ELEM(PCM_FLAG, 0) \
> +ELEM(PREV_INTRA_LUMA_PRED_FLAG, 1)\
> +ELEM(MPM_IDX, 0) \
> +ELEM(REM_INTRA_LUMA_PRED_MODE, 0) \
> +ELEM(INTRA_CHROMA_PRED_MODE, 2) \
> +ELEM(MERGE_FLAG, 1) \
> +ELEM(MERGE_IDX, 1)\
> +ELEM(INTER_PRED_IDC, 5) \
> +ELEM(REF_IDX_L0, 2) \
> +ELEM(REF_IDX_L1, 2) \
> +ELEM(ABS_MVD_GREATER0_FLAG, 2)\
> +ELEM(ABS_MVD_GREATER1_FLAG, 2)\
> +ELEM(ABS_MVD_MINUS2, 0) \
> +ELEM(MVD_SIGN_FLAG, 0)\
> +ELEM(MVP_LX_FLAG, 1) \
> +ELEM(NO_RESIDUAL_DATA_FLAG, 1)\
> +ELEM(SPLIT_TRANSFORM_FLAG, 3) \
> +ELEM(CBF_LUMA, 2) \
> +ELEM(CBF_CB_CR, 5)\
> +ELEM(TRANSFORM_SKIP_FLAG, 2) \
> +ELEM(EXPLICIT_RDPCM_FLAG, 2) \
> +ELEM(EXPLICIT_RDPCM_DIR_FLAG, 2) \
> +ELEM(LAST_SIGNIFICANT_COEFF_X_PREFIX,
Re: [FFmpeg-devel] [PATCH] fate: fix generating references when sh=dash
On Tue, 12 Mar 2024, Nicolas Gaullier wrote:
Regression since 0b98f28c46a7e3e914c51debc461
Signed-off-by: Nicolas Gaullier
---
tests/fate-run.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 0fead78c58..9863e4f2d9 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -672,7 +672,7 @@ else
fi
echo "${test}:${sig:-$err}:$cmpo:$erro" >$repfile
-if test $err != 0 && test $gen != "no" && test "${ref#tests/data/}" == "$ref"
; then
+if test $err != 0 && test $gen != "no" && test "${ref#tests/data/}" = "$ref" ;
then
echo "GEN $ref"
cp -f "$outfile" "$ref"
err=$?
--
Will apply.
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 1/1] avformat/gopher: Add audio and video itemtypes
On Tue, 5 Mar 2024, Christian Lee Seibold wrote:
The 's', ';', and '<' itemtypes are used for audio and video by
Gophernicus and Gopher+.
Signed-off-by: Christian Lee Seibold
---
libavformat/gopher.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/gopher.c b/libavformat/gopher.c
index 9497ffacf2..97ac9028a1 100644
--- a/libavformat/gopher.c
+++ b/libavformat/gopher.c
@@ -49,6 +49,9 @@ static int gopher_connect(URLContext *h, const char *path)
if (!*path) return AVERROR(EINVAL);
switch (*++path) {
case '5':
+case 's':
+case '<':
+case ';':
case '9':
path = strchr(path, '/');
if (!path) return AVERROR(EINVAL);
Will apply.
Thanks,
Marton
--
2.41.0.windows.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 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/parser: Check next against buffer index
On Sat, Jun 24, 2023 at 10:13:48PM +0200, Reimar Döffinger wrote:
> Hi!
>
> > On 24 Jun 2023, at 21:14, Andreas Rheinhardt
> > wrote:
> >
> > Michael Niedermayer:
> >> Fixes: out of array access
> >> Fixes: crash-0d640731c7da52415670eb47a2af701cbe2e1a3b
> >>
> >> Found-by: Catena cyber
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavcodec/parser.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> >> index efc28b8918..db39e698ab 100644
> >> --- a/libavcodec/parser.c
> >> +++ b/libavcodec/parser.c
> >> @@ -214,7 +214,7 @@ int ff_combine_frame(ParseContext *pc, int next,
> >> for (; pc->overread > 0; pc->overread--)
> >> pc->buffer[pc->index++] = pc->buffer[pc->overread_index++];
> >>
> >> -if (next > *buf_size)
> >> +if (next > *buf_size || (next < -pc->index && next != END_NOT_FOUND))
> >> return AVERROR(EINVAL);
> >>
> >> /* flush remaining if EOF */
> >
> > Could you provide more details about this? E.g. which parser is this
> > about at all? And how can we actually come in this situation at all?
> > (Whenever I looked at ff_combine_frame() I do not really understand what
> > its invariants are supposed to be.)
>
> Yeah, when I looked at it I also felt like it has all kinds of
> assumptions/preconditions without which it will break, but those
> are not documented. Not really reviewable for correctness.
> The change I proposed to fix the same issue was as below. But
> note that it is not based on actual understanding, just that generally
> index, overread_index and buf_size are updated together so I
> thought it suspicious buf_size was not updated on realloc failure.
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -252,6 +252,7 @@ int ff_combine_frame(ParseContext *pc, int next,
>AV_INPUT_BUFFER_PADDING_SIZE);
> if (!new_buffer) {
> av_log(NULL, AV_LOG_ERROR, "Failed to reallocate parser buffer to
> %d\n", next + pc->index + AV_INPUT_BUFFER_PADDING_SIZE);
> +*buf_size =
> pc->overread_index =
> pc->index = 0;
> return AVERROR(ENOMEM);
It appears neither of the 2 fixes was applied
this is not ideal
I will apply reimars patch
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/ppc/h264dsp: Fix unaligned stores
Exposed by
http://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Signed-off-by: Andreas Rheinhardt
---
I only tested that it compiles (and the size of .text even
goes down a bit, presumably because of the elimination of
int_dst_stride (which basically means that the lowest two bits
of dst_stride had to be zeroed (because the compiler didn't
know that they already are zero)).
libavcodec/ppc/h264dsp.c | 35 +--
1 file changed, 17 insertions(+), 18 deletions(-)
diff --git a/libavcodec/ppc/h264dsp.c b/libavcodec/ppc/h264dsp.c
index c02733dda2..21f8c13ca9 100644
--- a/libavcodec/ppc/h264dsp.c
+++ b/libavcodec/ppc/h264dsp.c
@@ -401,30 +401,29 @@ static inline void write16x4(uint8_t *dst, int dst_stride,
register vec_u8 r0, register vec_u8 r1,
register vec_u8 r2, register vec_u8 r3) {
DECLARE_ALIGNED(16, unsigned char, result)[64];
-uint32_t *src_int = (uint32_t *)result, *dst_int = (uint32_t *)dst;
-int int_dst_stride = dst_stride/4;
+uint32_t *src_int = (uint32_t *)result;
vec_st(r0, 0, result);
vec_st(r1, 16, result);
vec_st(r2, 32, result);
vec_st(r3, 48, result);
/* FIXME: there has to be a better way */
-*dst_int = *src_int;
-*(dst_int+ int_dst_stride) = *(src_int + 1);
-*(dst_int+ 2*int_dst_stride) = *(src_int + 2);
-*(dst_int+ 3*int_dst_stride) = *(src_int + 3);
-*(dst_int+ 4*int_dst_stride) = *(src_int + 4);
-*(dst_int+ 5*int_dst_stride) = *(src_int + 5);
-*(dst_int+ 6*int_dst_stride) = *(src_int + 6);
-*(dst_int+ 7*int_dst_stride) = *(src_int + 7);
-*(dst_int+ 8*int_dst_stride) = *(src_int + 8);
-*(dst_int+ 9*int_dst_stride) = *(src_int + 9);
-*(dst_int+10*int_dst_stride) = *(src_int + 10);
-*(dst_int+11*int_dst_stride) = *(src_int + 11);
-*(dst_int+12*int_dst_stride) = *(src_int + 12);
-*(dst_int+13*int_dst_stride) = *(src_int + 13);
-*(dst_int+14*int_dst_stride) = *(src_int + 14);
-*(dst_int+15*int_dst_stride) = *(src_int + 15);
+AV_WN32(dst, src_int[0]);
+AV_WN32(dst + dst_stride, src_int[1]);
+AV_WN32(dst + 2 * dst_stride, src_int[2]);
+AV_WN32(dst + 3 * dst_stride, src_int[3]);
+AV_WN32(dst + 4 * dst_stride, src_int[4]);
+AV_WN32(dst + 5 * dst_stride, src_int[5]);
+AV_WN32(dst + 6 * dst_stride, src_int[6]);
+AV_WN32(dst + 7 * dst_stride, src_int[7]);
+AV_WN32(dst + 8 * dst_stride, src_int[8]);
+AV_WN32(dst + 9 * dst_stride, src_int[9]);
+AV_WN32(dst + 10 * dst_stride, src_int[10]);
+AV_WN32(dst + 11 * dst_stride, src_int[11]);
+AV_WN32(dst + 12 * dst_stride, src_int[12]);
+AV_WN32(dst + 13 * dst_stride, src_int[13]);
+AV_WN32(dst + 14 * dst_stride, src_int[14]);
+AV_WN32(dst + 15 * dst_stride, src_int[15]);
}
/** @brief performs a 6x16 transpose of data in src, and stores it to dst
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Change rdiv (vf_convolution) documentation to reflect actual behavior
The documentation correctly states that the rdiv is a multiplier but
incorrectly states the default behavior is to multiply by the sum of all matrix
elements - it multiplies by 1/sum.
This changes the documentation to match the code.
---
doc/filters.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index e0436a5755..913365671d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10497,7 +10497,7 @@ and from 1 to 49 odd number of signed integers in
@var{row} mode.
@item 2rdiv
@item 3rdiv
Set multiplier for calculated value for each plane.
-If unset or 0, it will be sum of all matrix elements.
+If unset or 0, it will be 1/sum of all matrix elements.
@item 0bias
@item 1bias
--
2.44.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] fftools/opt_common: remove dead code in print_buildconf()
I found this code block when looking at this warning thrown in my
compiler (gcc 11.4.0 x86_64-linux-gnu):
```
In function ‘print_buildconf’,
inlined from ‘show_buildconf’ at fftools/opt_common.c:260:5:
fftools/opt_common.c:226:49: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
226 | remove_tilde[sizeof("pkg-config~") - 2] = ' ';
| ^
fftools/opt_common.c: In function ‘show_buildconf’:
fftools/opt_common.c:214:10: note: at offset [10, 11] into destination object
‘str’ of size 1
214 | char str[] = { FFMPEG_CONFIGURATION };
| ^~~
```
Upon further inspection, I am convinced that remove_tilde does not serve
a functional purpose. There are no other occurences in the FFmpeg
tree via grep, and we are setting a value in it but never using.
The original code traces back to 69cf626f9c1ba29e66ff62e2b835dcfc3031db8d
and even there, I cannot find a purpose for it.
Remove the variable and it's related loop where the assignment occurs,
which resolves the warning.
Signed-off-by: Marth64
---
fftools/opt_common.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index 947a226d8d..e4a63f565e 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -212,7 +212,7 @@ static void print_buildconf(int flags, int level)
{
const char *indent = flags & INDENT ? " " : "";
char str[] = { FFMPEG_CONFIGURATION };
-char *conflist, *remove_tilde, *splitconf;
+char *conflist, *splitconf;
// Change all the ' --' strings to '~--' so that
// they can be identified as tokens.
@@ -220,12 +220,6 @@ static void print_buildconf(int flags, int level)
conflist[0] = '~';
}
-// Compensate for the weirdness this would cause
-// when passing 'pkg-config --static'.
-while ((remove_tilde = strstr(str, "pkg-config~")) != NULL) {
-remove_tilde[sizeof("pkg-config~") - 2] = ' ';
-}
-
splitconf = strtok(str, "~");
av_log(NULL, level, "\n%sconfiguration:\n", indent);
while (splitconf != 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".
Re: [FFmpeg-devel] [PATCH] fftools/opt_common: remove dead code in print_buildconf()
Marth64:
> I found this code block when looking at this warning thrown in my
> compiler (gcc 11.4.0 x86_64-linux-gnu):
>
> ```
> In function ‘print_buildconf’,
> inlined from ‘show_buildconf’ at fftools/opt_common.c:260:5:
> fftools/opt_common.c:226:49: warning: writing 1 byte into a region of size 0
> [-Wstringop-overflow=]
> 226 | remove_tilde[sizeof("pkg-config~") - 2] = ' ';
> | ^
> fftools/opt_common.c: In function ‘show_buildconf’:
> fftools/opt_common.c:214:10: note: at offset [10, 11] into destination object
> ‘str’ of size 1
> 214 | char str[] = { FFMPEG_CONFIGURATION };
> | ^~~
> ```
>
> Upon further inspection, I am convinced that remove_tilde does not serve
> a functional purpose. There are no other occurences in the FFmpeg
> tree via grep, and we are setting a value in it but never using.
> The original code traces back to 69cf626f9c1ba29e66ff62e2b835dcfc3031db8d
> and even there, I cannot find a purpose for it.
>
> Remove the variable and it's related loop where the assignment occurs,
> which resolves the warning.
>
> Signed-off-by: Marth64
> ---
> fftools/opt_common.c | 8 +---
> 1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/fftools/opt_common.c b/fftools/opt_common.c
> index 947a226d8d..e4a63f565e 100644
> --- a/fftools/opt_common.c
> +++ b/fftools/opt_common.c
> @@ -212,7 +212,7 @@ static void print_buildconf(int flags, int level)
> {
> const char *indent = flags & INDENT ? " " : "";
> char str[] = { FFMPEG_CONFIGURATION };
> -char *conflist, *remove_tilde, *splitconf;
> +char *conflist, *splitconf;
>
> // Change all the ' --' strings to '~--' so that
> // they can be identified as tokens.
> @@ -220,12 +220,6 @@ static void print_buildconf(int flags, int level)
> conflist[0] = '~';
> }
>
> -// Compensate for the weirdness this would cause
> -// when passing 'pkg-config --static'.
> -while ((remove_tilde = strstr(str, "pkg-config~")) != NULL) {
> -remove_tilde[sizeof("pkg-config~") - 2] = ' ';
> -}
> -
> splitconf = strtok(str, "~");
> av_log(NULL, level, "\n%sconfiguration:\n", indent);
> while (splitconf != NULL) {
The code block changes str and str is later accessed (via splitconf).
- 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".
Re: [FFmpeg-devel] [PATCH] fftools/opt_common: remove dead code in print_buildconf()
> The code block changes str and str is later accessed (via splitconf). Sorry, for the lack of awareness, but I am confused how. strstr() shouldn't modify the string right? The only change I see is in the unused remove_tilde[] Thank you, for taking a look and explaining. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/avidec: Fix integer overflow iff ULONG_MAX < INT64_MAX
Affects many FATE-tests, see
http://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Signed-off-by: Andreas Rheinhardt
---
libavformat/avidec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index f3183b2698..b7cbf148af 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1696,7 +1696,7 @@ static int check_stream_max_drift(AVFormatContext *s)
int *idx = av_calloc(s->nb_streams, sizeof(*idx));
if (!idx)
return AVERROR(ENOMEM);
-for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos + 1LU) {
+for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos + (uint64_t)1)
{
int64_t max_dts = INT64_MIN / 2;
int64_t min_dts = INT64_MAX / 2;
int64_t max_buffer = 0;
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/opt_common: remove dead code in print_buildconf()
Marth64: >> The code block changes str and str is later accessed (via splitconf). > Sorry, for the lack of awareness, but I am confused how. > strstr() shouldn't modify the string right? > The only change I see is in the unused remove_tilde[] > No, but strstr() returns a pointer pointing into the string that is used to modify str. - 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".
Re: [FFmpeg-devel] [PATCH] avformat/avidec: Fix integer overflow iff ULONG_MAX < INT64_MAX
On 3/12/2024 7:57 PM, Andreas Rheinhardt wrote:
Affects many FATE-tests, see
http://fate.ffmpeg.org/report.cgi?time=20240312011016&slot=ppc-linux-gcc-13.2-ubsan-altivec-qemu
Signed-off-by: Andreas Rheinhardt
---
libavformat/avidec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index f3183b2698..b7cbf148af 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1696,7 +1696,7 @@ static int check_stream_max_drift(AVFormatContext *s)
int *idx = av_calloc(s->nb_streams, sizeof(*idx));
if (!idx)
return AVERROR(ENOMEM);
-for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos + 1LU) {
+for (min_pos = pos = 0; min_pos != INT64_MAX; pos = min_pos + (uint64_t)1)
{
nit: 1ULL
int64_t max_dts = INT64_MIN / 2;
int64_t min_dts = INT64_MAX / 2;
int64_t max_buffer = 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".
