[FFmpeg-devel] [PATCH] configure: add threads dep for vulkan
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" -- 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] lavc/vvc: AVERROR_PATCHWELCOME for subpictures
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 > ___ > 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] change av_ts_make_time_string precision
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
Re: [FFmpeg-devel] [PATCH v2] avcodec/ccaption_dec: honor transparency of leading non-breaking space
I am working on an improved patchset to consolidate these patches, also
address feedback and other improvements. Will submit soon, thank you!
On Mon, Mar 11, 2024 at 11:38 AM Stefano Sabatini
wrote:
> On date Sunday 2024-03-10 19:44:11 -0500, Marth64 wrote:
> > In Closed Captions (US), the non-breaking space (0xA0) can be used to
> align
> > text horizontally from the left by using it 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 over 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.
> >
> > v2 only updates the commit message which mistakenly referenced avformat.
> >
> > Signed-off-by: Marth64
> > ---
> > libavcodec/ccaption_dec.c | 9 ++---
> > 1 file changed, 6 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> > index faf058ce97..591013d202 100644
> > --- a/libavcodec/ccaption_dec.c
> > +++ b/libavcodec/ccaption_dec.c
> > @@ -91,7 +91,7 @@ enum cc_charset {
> > ENTRY(0x36, "\u00a3")\
> > ENTRY(0x37, "\u266a")\
> > ENTRY(0x38, "\u00e0")\
> > -ENTRY(0x39, "\u00A0")\
> > +ENTRY(0x39, "\u00a0")\
> > ENTRY(0x3a, "\u00e8")\
> > ENTRY(0x3b, "\u00e2")\
> > ENTRY(0x3c, "\u00ea")\
> > @@ -471,7 +471,8 @@ static int capture_screen(CCaptionSubContext *ctx)
> > const char *row = screen->characters[i];
> > const char *charset = screen->charsets[i];
> > j = 0;
> > -while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN)
> > +while ((row[j] == ' ' && charset[j] ==
> CCSET_BASIC_AMERICAN) ||
> > + (row[j] == 0x39 && charset[j] ==
> CCSET_SPECIAL_AMERICAN))
> > j++;
> > if (!tab || j < tab)
> > tab = j;
> > @@ -491,7 +492,9 @@ static int capture_screen(CCaptionSubContext *ctx)
> > j = 0;
> >
> > /* skip leading space */
> > -while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN
> && j < tab)
> > +while (j < tab &&
> > + (row[j] == ' ' && charset[j] ==
> CCSET_BASIC_AMERICAN) ||
> > + (row[j] == 0x39 && charset[j] ==
> CCSET_SPECIAL_AMERICAN))
> > j++;
>
> Patch LGTM, will apply the complete patcheset if I see no comments
> after a few days.
>
> 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] Relative paths vs. filenames in #includes for project files.
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. ___ 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/ccaption_dec: don't print multiple \pos tags per cue
Thanks, will follow up with a v3 set (consolidating/resolving feedback on the other CC fixes as well). ___ 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 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). Maybe the crashes can be fixed in some other form? And abort only if FF_COMPLIANCE_STRICT is requested. ___ 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 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 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: extract only one type of CC substream
Agreed on both points, I will address them. 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] [libavutil/timestamp.h: Fix loss of precision in timestamps for silencedetect on long files]
> On Monday, March 11, 2024 at 12:50:11 PM PDT, wrote:
> On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
>> Andreas Rheinhardt:
>>> 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
Re: [FFmpeg-devel] [PATCH v2 1/4] avcodec/aom_film_grain: add AOM film grain synthesis
On 08/03/2024 13:44, Niklas Haas wrote: On Fri, 08 Mar 2024 10:31:28 -0300 James Almer wrote: On 3/8/2024 10:21 AM, Niklas Haas wrote: From: Niklas Haas Implementation copied wholesale from dav1d, sans SIMD, under permissive license. This implementation was extensively verified to be bit-exact, so it serves as a much better starting point than trying to re-engineer this from scratch for no reason. (I also authored the original implementation in dav1d, so any "clean room" implementation would end up looking much the same, anyway) The notable changes I had to make while adapting this from the dav1d code-base to the FFmpeg codebase include: - reordering variable declarations to avoid triggering warnings - replacing several inline helpers by avutil equivalents - changing code that accesses frame metadata - replacing raw plane copying logic by av_image_copy_plane Apart from this, the implementation is basically unmodified. Do we want this to be public? Both as a struct and the decoding functions. It could be used by libavfilter or even outside our libraries. The hevc decoder would export the relevant T.35 SEI in the new struct if told to not apply fg, like we already do in av1. I'm not sure if the AFGS1 struct itself needs to be public, since it is largely just a codec-internal wrapper for multiple param sets (for scalable codecs). 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. (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".
Re: [FFmpeg-devel] [PATCH] avcodec/ccaption_dec: don't print multiple \pos tags per cue
On 3/11/24 17:48, Marth64 wrote: This breaks fate Looking into it - thanks. It is possible that the change is correct, and that the fate test needs to be changed to reflect the correct behavior. Not necessarily, but possibly. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/ccaption_dec: don't print multiple \pos tags per cue
> This breaks fate Looking into it - thanks. PS, sorry for previous top-posting in replies. Will be more cautious of that. ___ 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/ccaption_dec: don't print multiple \pos tags per cue
On Sun, Mar 10, 2024 at 07:40:47PM -0500, Marth64 wrote:
> Currently, Closed Captions decoder prints multiple \pos ASS tags per line,
> per cue. This is invalid behavior, because only the first \pos tag in a cue
> is honored by ASS anyway. Don't write multiple \pos tags.
>
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
This breaks fate
--- ./tests/ref/fate/sub-cc-scte20 2024-03-05 02:37:36.22323 +0100
+++ tests/data/fate/sub-cc-scte20 2024-03-11 22:13:08.091910294 +0100
@@ -13,5 +13,5 @@
[Events]
Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
Dialogue: 0,0:00:00.00,0:00:01.44,Default,,0,0,0,,{\an7}{\pos(48,182)}BESIDES
THE
-Dialogue:
0,0:00:01.43,0:00:03.93,Default,,0,0,0,,{\an7}{\pos(38,166)}\hBESIDES THE
\N{\an7}{\pos(38,197)}SPENDING AND THIS, IS THAT CAR
-Dialogue: 0,0:00:03.94,0:00:06.31,Default,,0,0,0,,{\an7}{\pos(38,182)}SPENDING
AND THIS, IS THAT CAR \N{\an7}{\pos(38,197)}MANUFACTURERS ARE ABOUT AS
+Dialogue:
0,0:00:01.43,0:00:03.93,Default,,0,0,0,,{\an7}{\pos(38,166)}\hBESIDES THE
\NSPENDING AND THIS, IS THAT CAR
+Dialogue: 0,0:00:03.94,0:00:06.31,Default,,0,0,0,,{\an7}{\pos(38,182)}SPENDING
AND THIS, IS THAT CAR \NMANUFACTURERS ARE ABOUT AS
Test sub-cc-scte20 failed. Look at tests/data/fate/sub-cc-scte20.err for
details.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Nations do behave wisely once they have exhausted all other alternatives.
-- Abba Eban
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Indefinite ban request [RFC] Was: Re: [FFmpeg-trac] #10882(undetermined:new): swscale wastefully scales luma during yuv420p -> yuv422p
On 3/9/24 20:25, Michael Niedermayer wrote: Hi everyone 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. As reference, and to make it possible for the community to discuss this easily without too much google searching. Ive attached the list of all changes in trac done by Balling. I do not and never did support permanently banning contributors. In summary: since 2019 842 comment0' changed 389 comment1' changed 176 comment2' changed 87 comment3' changed 49 comment4' changed 24 comment5' changed 12 comment6' changed 6 comment7' changed 4 comment8' changed 3 comment9' changed 2194 comment' changed 10 component' changed 12 description' changed 29 keywords' changed 37 owner' changed 8 priority' changed 7 reproduced' changed 291 resolution' changed 537 status' changed 32 summary' changed 2 type' changed 11 version' changed If these are supposed to be ticket numbers on the left, I checked the first two and neither have comments from Balling. If these are summaries/counts on the left, could you please elaborate on how you generated this data? I'm not super familiar with the trac user interface, but iirc you can embed the search in a query string. - Leo Izen (Traneptora) OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Fwd: patch for 44.1/32 khz pcm input in pcm dvd encoder
Hi Andrew, Sorry, it took me some time to author DVDs to test this but I finally got around to it. DVD player # 1 (DVD only) -- pass for both 32k and 44.1k DVD player # 2 (4K/BD/DVD) -- pass for both 32k and 44.1k Interestingly, DVD player # 2 OSD showed sample rate as 48k but anyways it played fine. So, I agree this is supported most likely transparently by the decoder chipset itself. WRT the patch itself. I noticed there is an indentation issue in the switch statement, and it did not apply automatically on latest master. I had to modify it to apply. I do not have permission to merge patches but I imagine this will be more likely to get merged with those 2 things fixed. out of curiosity, how did you get the constant values ? (44.1 = 2, 32 = 3). I would like to implement this as well in to the DVD demuxer, since apparently it is possible to do. Thanks for sharing. Respectfully, On Tue, Jan 30, 2024 at 11:41 PM Andrew Randrianasulu < randrianas...@gmail.com> wrote: > ср, 31 янв. 2024 г., 04:49 Andrew Randrianasulu : > > > > > > > вт, 30 янв. 2024 г., 23:21 Marth64 : > > > >> Interesting, thanks. My thought was to see if this is allowed for > >> DVD-Video vs DVD-Audio only which are different application layer. I can > >> try to run a PS2 test with the real hardware out of curiosity later. > >> > > > > Thanks! > > > > > > I also found Cirrus Logic application note from 2001 that mentions 32khz > > pcm operation. Yet it looks more like external amplifier/decoder part, > not > > something integrated into dvd player itself? (input stream via S/PDIF) > > > > https://pdf.dzsc.com/9/28162.pdf > > > > > https://tascam.com/downloads/tascam/78/DV-D01U_Manual.pdf > > also this pdf lists dvd pcm 44.1 in table at p. 30. > > No sights of 32khz, but surprizingly hdmi can carry such low frequency > sampled sounds! > > > > > > > > > > >> On Tue, Jan 30, 2024 at 2:17 PM Andrew Randrianasulu < > >> randrianas...@gmail.com> wrote: > >> > >> > пн, 29 янв. 2024 г., 22:08 Andrew Randrianasulu < > >> randrianas...@gmail.com>: > >> > > >> > > On Mon, Jan 29, 2024 at 8:16 PM Marth64 > wrote: > >> > > > > >> > > > Hi, out of curiosity, I did not know 44.1/32 is supported on DVD > >> PCM. > >> > > Does > >> > > > this type of output work on an actual DVD player? > >> > > > >> > > >> > > >> > At least this pdf brochure lists 44.1 under PCM: > >> > > >> > > >> > > >> > https://at.yamaha.com/files/download/other_assets/8/333768/DVD-S1500_e_U.pdf > >> > > >> > > >> > > We try to determinate this, but unfortunately new DVD players a bit > >> > > TOO flexible and forgiving? > >> > > > >> > > > https://lists.cinelerra-gg.org/pipermail/cin/2024-January/007907.html > >> > > > >> > > I even had idea to use PS2 emulator to check (DVD video supposed to > >> > > work there since some time) > >> > > but ran into qt6 being build dependency ... so I shelved this idea > >> for > >> > > now > >> > > > >> > > > >> > > > >> > > > >> > > Thank you > >> > > > > >> > > > On Mon, Jan 22, 2024 at 3:59 AM Andrew Randrianasulu < > >> > > > randrianas...@gmail.com> wrote: > >> > > > > >> > > > > -- Forwarded message - > >> > > > > От: Andrew Randrianasulu > >> > > > > Date: вс, 21 янв. 2024 г., 06:49 > >> > > > > Subject: patch for 44.1/32 khz pcm input in pcm dvd encoder > >> > > > > To: FFmpeg user questions , > Cinelerra.GG > >> < > >> > > > > c...@lists.cinelerra-gg.org> > >> > > > > > >> > > > > > >> > > > > relative to ffmpeg.git commit > >> > 6c4388b468bf92c0c1e7733c6cfe4ff3f9ca9723 > >> > > > > > >> > > > > lightly tested with mpv and mediainfo like this: > >> > > > > > >> > > > > ./ffmpeg -i ~/f9518976.mp4 -target pal-dvd -ar 44100 -c:a > pcm_dvd > >> -f > >> > > dvd > >> > > > > t.mpg > >> > > > > > >> > > > > mpv plays sound correctly, mediainfo does not know those > >> frequencies > >> > > and > >> > > > > display 0khz. ;) > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > forwarded to ffmpeg-devel as requested. > >> > > > > ___ > >> > > > > ffmpeg-devel mailing list > >> > > > > ffmpeg-devel@ffmpeg.org > >> > > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > > > > >> > > > > To unsubscribe, visit link above, or email > >> > > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> > > > > > >> > > > ___ > >> > > > ffmpeg-devel mailing list > >> > > > ffmpeg-devel@ffmpeg.org > >> > > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > > > > >> > > > To unsubscribe, visit link above, or email > >> > > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > >> > > > >> > ___ > >> > ffmpeg-devel 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 v8 14/14] avcodec/libx265: add support for writing out CLL and MDCV
The newer of these two are the separate integers for content light
level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
with X265_BUILD 75. As we already require X265_BUILD of at least
89, no further conditions are required.
---
libavcodec/libx265.c | 88
tests/fate/enc_external.mak | 5 ++
tests/ref/fate/libx265-hdr10 | 16 +++
3 files changed, 109 insertions(+)
create mode 100644 tests/ref/fate/libx265-hdr10
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 92183b9ca2..b77da1c2f1 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -28,9 +28,11 @@
#include
#include "libavutil/avassert.h"
+#include "libavutil/bprint.h"
#include "libavutil/buffer.h"
#include "libavutil/internal.h"
#include "libavutil/common.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "avcodec.h"
@@ -176,6 +178,85 @@ static av_cold int libx265_param_parse_int(AVCodecContext
*avctx,
return 0;
}
+static int handle_mdcv(const AVClass **avcl, const x265_api *api,
+ x265_param *params,
+ const AVMasteringDisplayMetadata *mdcv)
+{
+int ret = AVERROR_BUG;
+AVBPrint buf;
+av_bprint_init(, 0, AV_BPRINT_SIZE_AUTOMATIC);
+
+// G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)
+av_bprintf(
+,
+"G(%"PRId64",%"PRId64")B(%"PRId64",%"PRId64")R(%"PRId64",%"PRId64")"
+"WP(%"PRId64",%"PRId64")L(%"PRId64",%"PRId64")",
+av_rescale_q(1, mdcv->display_primaries[1][0], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->display_primaries[1][1], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->display_primaries[2][0], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->display_primaries[2][1], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->display_primaries[0][0], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->display_primaries[0][1], (AVRational){ 1, 5
}),
+av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 }),
+av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 }),
+av_rescale_q(1, mdcv->max_luminance, (AVRational){ 1, 1 }),
+av_rescale_q(1, mdcv->min_luminance, (AVRational){ 1, 1 }));
+
+if (!av_bprint_is_complete()) {
+av_log(avcl, AV_LOG_ERROR,
+ "MDCV string too long for its available space!\n");
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+if (api->param_parse(params, "master-display", buf.str) ==
+X265_PARAM_BAD_VALUE) {
+av_log(avcl, AV_LOG_ERROR,
+ "Invalid value \"%s\" for param \"master-display\".\n",
+ buf.str);
+ret = AVERROR(EINVAL);
+goto end;
+}
+
+ret = 0;
+
+end:
+av_bprint_finalize(, NULL);
+
+return ret;
+}
+
+static int handle_side_data(AVCodecContext *avctx, const x265_api *api,
+x265_param *params)
+{
+const AVFrameSideData *cll_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+params->maxCLL = cll->MaxCLL;
+params->maxFALL = cll->MaxFALL;
+}
+
+if (mdcv_sd) {
+int ret = handle_mdcv(
+>av_class, api, params,
+(AVMasteringDisplayMetadata *)mdcv_sd->data);
+if (ret < 0)
+return ret;
+}
+
+return 0;
+}
+
static av_cold int libx265_encode_init(AVCodecContext *avctx)
{
libx265Context *ctx = avctx->priv_data;
@@ -336,6 +417,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR_BUG;
}
+ret = handle_side_data(avctx, ctx->api, ctx->params);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed handling side data! (%s)\n",
+ av_err2str(ret));
+return ret;
+}
+
if (ctx->crf >= 0) {
char crf[6];
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
index 4095a4b51a..30021efbcd 100644
--- a/tests/fate/enc_external.mak
+++ b/tests/fate/enc_external.mak
@@ -12,5 +12,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 HEVC, MOV,
LIBX264_HDR10 HEVC_DEMUXER H
fate-libx264-hdr10: CMD = enc_external
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
mp4 "-c:v libx264" "-show_frames -show_entries frame=side_data_list -of
flat"
+# test for x265 MDCV and CLL passthrough during encoding
+FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX265 HEVC, MOV, HEVC_DEMUXER) +=
fate-libx265-hdr10
[FFmpeg-devel] [PATCH v8 13/14] avcodec/libx264: add support for writing out CLL and MDCV
Both of these two structures were first available with X264_BUILD
163, so make relevant functionality conditional on the version
being at least such.
Keep handle_side_data available in all cases as this way X264_init
does not require additional version based conditions within it.
Finally, add a FATE test which verifies that pass-through of the
MDCV/CLL side data is working during encoding.
---
configure| 2 +
libavcodec/libx264.c | 79
tests/fate/enc_external.mak | 5 +++
tests/ref/fate/libx264-hdr10 | 15 +++
4 files changed, 101 insertions(+)
create mode 100644 tests/ref/fate/libx264-hdr10
diff --git a/configure b/configure
index 05f8283af9..fe883cff5f 100755
--- a/configure
+++ b/configure
@@ -2531,6 +2531,7 @@ CONFIG_EXTRA="
jpegtables
lgplv3
libx262
+libx264_hdr10
llauddsp
llviddsp
llvidencdsp
@@ -6927,6 +6928,7 @@ enabled libx264 && require_pkg_config libx264
x264 "stdint.h x264.h" x
require_cpp_condition libx264 x264.h "X264_BUILD
>= 122" && {
[ "$toolchain" != "msvc" ] ||
require_cpp_condition libx264 x264.h "X264_BUILD
>= 158"; } &&
+ check_cpp_condition libx264_hdr10 x264.h
"X264_BUILD >= 163" &&
check_cpp_condition libx262 x264.h "X264_MPEG2"
enabled libx265 && require_pkg_config libx265 x265 x265.h
x265_api_get &&
require_cpp_condition libx265 x265.h "X265_BUILD
>= 89"
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 0997c4e134..afeb285487 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -25,6 +25,7 @@
#include "libavutil/eval.h"
#include "libavutil/internal.h"
#include "libavutil/opt.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/mem.h"
#include "libavutil/pixdesc.h"
#include "libavutil/stereo3d.h"
@@ -853,6 +854,82 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
return AVERROR(EINVAL);\
}
+#if CONFIG_LIBX264_HDR10
+static void handle_mdcv(x264_param_t *params,
+const AVMasteringDisplayMetadata *mdcv)
+{
+if (!mdcv->has_primaries && !mdcv->has_luminance)
+return;
+
+params->mastering_display.b_mastering_display = 1;
+
+if (mdcv->has_primaries) {
+int *const points[][2] = {
+{
+>mastering_display.i_red_x,
+>mastering_display.i_red_y
+},
+{
+>mastering_display.i_green_x,
+>mastering_display.i_green_y
+},
+{
+>mastering_display.i_blue_x,
+>mastering_display.i_blue_y
+},
+};
+
+for (int i = 0; i < 3; i++) {
+const AVRational *src = mdcv->display_primaries[i];
+int *dst[2] = { points[i][0], points[i][1] };
+
+*dst[0] = av_rescale_q(1, src[0], (AVRational){ 1, 5 });
+*dst[1] = av_rescale_q(1, src[1], (AVRational){ 1, 5 });
+}
+
+params->mastering_display.i_white_x =
+av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 });
+params->mastering_display.i_white_y =
+av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 });
+}
+
+if (mdcv->has_luminance) {
+params->mastering_display.i_display_max =
+av_rescale_q(1, mdcv->max_luminance, (AVRational){ 1, 1 });
+params->mastering_display.i_display_min =
+av_rescale_q(1, mdcv->min_luminance, (AVRational){ 1, 1 });
+}
+}
+#endif // CONFIG_LIBX264_HDR10
+
+static void handle_side_data(AVCodecContext *avctx, x264_param_t *params)
+{
+#if CONFIG_LIBX264_HDR10
+const AVFrameSideData *cll_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+params->content_light_level.i_max_cll = cll->MaxCLL;
+params->content_light_level.i_max_fall = cll->MaxFALL;
+
+params->content_light_level.b_cll = 1;
+}
+
+if (mdcv_sd) {
+handle_mdcv(params, (AVMasteringDisplayMetadata *)mdcv_sd->data);
+}
+#endif // CONFIG_LIBX264_HDR10
+}
+
static av_cold int X264_init(AVCodecContext *avctx)
{
X264Context *x4 = avctx->priv_data;
@@ -1153,6 +1230,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
[FFmpeg-devel] [PATCH v8 12/14] avcodec/libsvtav1: add support for writing out CLL and MDCV
These two were added in 28e23d7f348c78d49a726c7469f9d4e38edec341
and 3558c1f2e97455e0b89edef31b9a72ab7fa30550 for version 0.9.0 of
SVT-AV1, which is also our minimum requirement right now.
In other words, no additional version limiting conditions seem
to be required.
Additionally, add a FATE test which verifies that pass-through of
the MDCV/CLL side data is working during encoding.
---
libavcodec/libsvtav1.c | 68 ++
tests/fate/enc_external.mak| 5 +++
tests/ref/fate/libsvtav1-hdr10 | 14 +++
3 files changed, 87 insertions(+)
create mode 100644 tests/ref/fate/libsvtav1-hdr10
diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index 7721e01677..66fa019aa0 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -27,6 +27,8 @@
#include "libavutil/common.h"
#include "libavutil/frame.h"
#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mastering_display_metadata.h"
#include "libavutil/opt.h"
#include "libavutil/pixdesc.h"
#include "libavutil/avassert.h"
@@ -136,6 +138,70 @@ static int alloc_buffer(EbSvtAv1EncConfiguration *config,
SvtContext *svt_enc)
}
+static void handle_mdcv(struct EbSvtAv1MasteringDisplayInfo *dst,
+const AVMasteringDisplayMetadata *mdcv)
+{
+if (mdcv->has_primaries) {
+const struct EbSvtAv1ChromaPoints *const points[] = {
+>r,
+>g,
+>b,
+};
+
+for (int i = 0; i < 3; i++) {
+const struct EbSvtAv1ChromaPoints *dst = points[i];
+const AVRational *src = mdcv->display_primaries[i];
+
+AV_WB16(>x,
+av_rescale_q(1, src[0], (AVRational){ 1, (1 << 16) }));
+AV_WB16(>y,
+av_rescale_q(1, src[1], (AVRational){ 1, (1 << 16) }));
+}
+
+AV_WB16(>white_point.x,
+av_rescale_q(1, mdcv->white_point[0],
+ (AVRational){ 1, (1 << 16) }));
+AV_WB16(>white_point.y,
+av_rescale_q(1, mdcv->white_point[1],
+ (AVRational){ 1, (1 << 16) }));
+}
+
+if (mdcv->has_luminance) {
+AV_WB32(>max_luma,
+av_rescale_q(1, mdcv->max_luminance,
+ (AVRational){ 1, (1 << 8) }));
+AV_WB32(>min_luma,
+av_rescale_q(1, mdcv->min_luminance,
+ (AVRational){ 1, (1 << 14) }));
+}
+}
+
+static void handle_side_data(AVCodecContext *avctx,
+ EbSvtAv1EncConfiguration *param)
+{
+const AVFrameSideData *cll_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_frame_side_data_get(
+(const AVFrameSideData **)avctx->frame_side_data,
+avctx->nb_frame_side_data,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+AV_WB16(>content_light_level.max_cll, cll->MaxCLL);
+AV_WB16(>content_light_level.max_fall, cll->MaxFALL);
+}
+
+if (mdcv_sd) {
+handle_mdcv(>mastering_display,
+(AVMasteringDisplayMetadata *)mdcv_sd->data);
+}
+}
+
static int config_enc_params(EbSvtAv1EncConfiguration *param,
AVCodecContext *avctx)
{
@@ -254,6 +320,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
/* 2 = IDR, closed GOP, 1 = CRA, open GOP */
param->intra_refresh_type = avctx->flags & AV_CODEC_FLAG_CLOSED_GOP ? 2 :
1;
+handle_side_data(avctx, param);
+
#if SVT_AV1_CHECK_VERSION(0, 9, 1)
while ((en = av_dict_get(svt_enc->svtav1_opts, "", en,
AV_DICT_IGNORE_SUFFIX))) {
EbErrorType ret = svt_av1_enc_parse_parameter(param, en->key,
en->value);
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
index 7eabebcc51..d787941c16 100644
--- a/tests/fate/enc_external.mak
+++ b/tests/fate/enc_external.mak
@@ -2,5 +2,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 H264, MOV,
H264_DEMUXER) += fate-libx26
fate-libx264-simple: CMD = enc_external
$(TARGET_SAMPLES)/h264-conformance/BA1_Sony_D.jsv \
mp4 "-c:v libx264" "-show_entries frame=width,height,pix_fmt,pts,pkt_dts
-of flat"
+# test for SVT-AV1 MDCV and CLL passthrough during encoding
+FATE_ENC_EXTERNAL-$(call ENCDEC, LIBSVTAV1 HEVC, MOV, HEVC_DEMUXER
LIBDAV1D_DECODER) += fate-libsvtav1-hdr10
+fate-libsvtav1-hdr10: CMD = enc_external
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
+mp4 "-c:v libsvtav1" "-show_frames -show_entries frame=side_data_list -of
flat"
+
FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_ENC_EXTERNAL-yes)
fate-enc-external: $(FATE_ENC_EXTERNAL-yes)
diff --git a/tests/ref/fate/libsvtav1-hdr10
[FFmpeg-devel] [PATCH v8 11/14] ffmpeg: pass first video AVFrame's side data to encoder
This enables further configuration of output based on the results
of input decoding and filtering in a similar manner as the color
information.
---
fftools/ffmpeg_enc.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index bdba50df03..5ec6ee17de 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -245,6 +245,16 @@ int enc_open(void *opaque, const AVFrame *frame)
enc_ctx->colorspace = frame->colorspace;
enc_ctx->chroma_sample_location = frame->chroma_location;
+ret = avcodec_configure_side_data(
+enc_ctx,
+(const AVFrameSideData **)frame->side_data, frame->nb_side_data,
+AV_FRAME_SIDE_DATA_FLAG_UNIQUE);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "failed to configure video encoder:
%s!\n",
+ av_err2str(ret));
+return ret;
+}
+
if (enc_ctx->flags & (AV_CODEC_FLAG_INTERLACED_DCT |
AV_CODEC_FLAG_INTERLACED_ME) ||
(frame->flags & AV_FRAME_FLAG_INTERLACED)
#if FFMPEG_OPT_TOP
--
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 v8 10/14] avcodec: add helper for configuring AVCodecContext's frame side data
This allows API clients that wish to configure multiple entries
at a time to do so without writing the looping code themselves.
---
libavcodec/avcodec.c | 30 ++
libavcodec/avcodec.h | 21 +
2 files changed, 51 insertions(+)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index a9a87bb58c..0ced87b946 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -686,3 +686,33 @@ int attribute_align_arg
avcodec_receive_frame(AVCodecContext *avctx, AVFrame *fr
return ff_decode_receive_frame(avctx, frame);
return ff_encode_receive_frame(avctx, frame);
}
+
+int avcodec_configure_side_data(AVCodecContext *avctx,
+const AVFrameSideData **sd, const int nb_sd,
+unsigned int flags)
+{
+if (!avctx)
+return AVERROR(EINVAL);
+
+if (!sd) {
+av_frame_side_data_free(
+>frame_side_data, >nb_frame_side_data);
+return 0;
+}
+
+if (nb_sd > 0 && nb_sd == avctx->nb_frame_side_data &&
+sd == (const AVFrameSideData **)avctx->frame_side_data)
+return AVERROR(EINVAL);
+
+for (int i = 0; i < nb_sd; i++) {
+int ret = av_frame_side_data_clone(
+>frame_side_data, >nb_frame_side_data, sd[i], flags);
+if (ret < 0) {
+av_frame_side_data_free(
+>frame_side_data, >nb_frame_side_data);
+return ret;
+}
+}
+
+return 0;
+}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 432a3fd153..6de4dc0f7b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3075,6 +3075,27 @@ void av_fast_padded_mallocz(void *ptr, unsigned int
*size, size_t min_size);
*/
int avcodec_is_open(AVCodecContext *s);
+/**
+ * Add multiple side data entries to an AVCodecContext's array in one go, for
+ * example from an AVFrame.
+ *
+ * In case the function fails to add a side data entry, it will clear the
+ * whole side data set.
+ *
+ * @param avctx context to which the side data should be added
+ * @param sdarray of side data to use as input.
+ * if null, clears out the side data for this context.
+ * @param nb_sd integer containing the number of entries in the array.
+ * @param flags Some combination of AV_FRAME_SIDE_DATA_SET_FLAG_* flags, or 0.
+ *
+ * @return negative error code on failure, >=0 on success.
+ *
+ * @see av_frame_side_data_new regarding the flags.
+ */
+int avcodec_configure_side_data(AVCodecContext *avctx,
+const AVFrameSideData **sd, const int nb_sd,
+unsigned int flags);
+
/**
* @}
*/
--
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 v8 09/14] avcodec: add frame side data array to AVCodecContext
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
+ */
+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(>inter_matrix);
av_freep(>rc_override);
av_channel_layout_uninit(>ch_layout);
+av_frame_side_data_free(
+>frame_side_data, >nb_frame_side_data);
av_freep(pavctx);
}
--
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 v8 08/14] avutil/frame: add helper for getting side data from array
---
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);
+
/**
* @}
*/
--
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 v8 07/14] avutil/frame: add helper for adding side data w/ AVBufferRef to array
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();
-return AVERROR(ENOMEM);
+av_buffer_unref(_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(_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.
--
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 v8 06/14] avutil/frame: add helper for adding existing side data to array
---
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();
+
+((*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();
+return AVERROR(ENOMEM);
+}
+
+ret = av_dict_copy(_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);
+
/**
* @}
*/
--
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 v8 05/14] avutil/frame: add helper for adding side data to array
Additionally, add an API test to check that the no-duplicates
addition works after duplicates have been inserted.
---
libavutil/Makefile | 1 +
libavutil/frame.c | 17 ++
libavutil/frame.h | 22 +++
libavutil/tests/side_data_set.c | 103
tests/fate/libavutil.mak| 4 ++
tests/ref/fate/side_data_set| 14 +
6 files changed, 161 insertions(+)
create mode 100644 libavutil/tests/side_data_set.c
create mode 100644 tests/ref/fate/side_data_set
diff --git a/libavutil/Makefile b/libavutil/Makefile
index e7709b97d0..4415c913a1 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -271,6 +271,7 @@ TESTPROGS = adler32
\
ripemd \
sha \
sha512 \
+side_data_set \
softfloat \
tree\
twofish \
diff --git a/libavutil/frame.c b/libavutil/frame.c
index dd27456031..4074391a92 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -747,6 +747,23 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
return ret;
}
+AVFrameSideData *av_frame_side_data_new(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+size_t size, unsigned int flags)
+{
+AVBufferRef *buf = av_buffer_alloc(size);
+AVFrameSideData *ret = NULL;
+
+if (flags & AV_FRAME_SIDE_DATA_FLAG_UNIQUE)
+remove_side_data(sd, nb_sd, type);
+
+ret = add_side_data_to_set_from_buf(sd, nb_sd, type, buf);
+if (!ret)
+av_buffer_unref();
+
+return ret;
+}
+
AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
enum AVFrameSideDataType type)
{
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 27281c168f..5d68d1e7af 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -999,6 +999,28 @@ const char *av_frame_side_data_name(enum
AVFrameSideDataType type);
*/
void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
+#define AV_FRAME_SIDE_DATA_FLAG_UNIQUE (1 << 0)
+
+/**
+ * Add new side data entry to an array.
+ *
+ * @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 size size of the side data
+ * @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_new(AVFrameSideData ***sd, int *nb_sd,
+enum AVFrameSideDataType type,
+size_t size, unsigned int flags);
+
/**
* @}
*/
diff --git a/libavutil/tests/side_data_set.c b/libavutil/tests/side_data_set.c
new file mode 100644
index 00..793a62c009
--- /dev/null
+++ b/libavutil/tests/side_data_set.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2023 Jan Ekström
+ *
+ * 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/frame.c"
+#include "libavutil/mastering_display_metadata.h"
+
+static void print_clls(const AVFrameSideData **sd, const int nb_sd)
+{
+for (int i = 0; i < nb_sd; i++) {
+const AVFrameSideData *entry = sd[i];
+
+printf("sd %d, %s",
+ i, av_frame_side_data_name(entry->type));
+
+if (entry->type != AV_FRAME_DATA_CONTENT_LIGHT_LEVEL) {
+putchar('\n');
+continue;
+}
[FFmpeg-devel] [PATCH v8 04/14] avutil/frame: split side data removal out to non-AVFrame function
This will make it possible to reuse logic in further commits.
---
libavutil/frame.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 9ebe830c5c..dd27456031 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -83,6 +83,21 @@ void av_frame_side_data_free(AVFrameSideData ***sd, int
*nb_sd)
wipe_side_data(sd, nb_sd);
}
+static void remove_side_data(AVFrameSideData ***sd, int *nb_side_data,
+ const enum AVFrameSideDataType type)
+{
+for (int i = *nb_side_data - 1; i >= 0; i--) {
+AVFrameSideData *entry = ((*sd)[i]);
+if (entry->type != type)
+continue;
+
+free_side_data();
+
+((*sd)[i]) = ((*sd)[*nb_side_data - 1]);
+(*nb_side_data)--;
+}
+}
+
AVFrame *av_frame_alloc(void)
{
AVFrame *frame = av_malloc(sizeof(*frame));
@@ -801,14 +816,7 @@ int av_frame_copy(AVFrame *dst, const AVFrame *src)
void av_frame_remove_side_data(AVFrame *frame, enum AVFrameSideDataType type)
{
-for (int i = frame->nb_side_data - 1; i >= 0; i--) {
-AVFrameSideData *sd = frame->side_data[i];
-if (sd->type == type) {
-free_side_data(>side_data[i]);
-frame->side_data[i] = frame->side_data[frame->nb_side_data - 1];
-frame->nb_side_data--;
-}
-}
+remove_side_data(>side_data, >nb_side_data, type);
}
const char *av_frame_side_data_name(enum AVFrameSideDataType type)
--
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 v8 03/14] avutil/frame: split side_data_from_buf to base and AVFrame func
---
libavutil/frame.c | 25 +
1 file changed, 17 insertions(+), 8 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index baac0706db..9ebe830c5c 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -679,23 +679,23 @@ AVBufferRef *av_frame_get_plane_buffer(const AVFrame
*frame, int plane)
return NULL;
}
-AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
- enum AVFrameSideDataType type,
- AVBufferRef *buf)
+static AVFrameSideData *add_side_data_to_set_from_buf(AVFrameSideData ***sd,
+ int *nb_sd,
+ enum AVFrameSideDataType
type,
+ AVBufferRef *buf)
{
AVFrameSideData *ret, **tmp;
if (!buf)
return NULL;
-if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
+if (*nb_sd > INT_MAX / sizeof(*sd) - 1)
return NULL;
-tmp = av_realloc(frame->side_data,
- (frame->nb_side_data + 1) * sizeof(*frame->side_data));
+tmp = av_realloc(*sd, (*nb_sd + 1) * sizeof(*sd));
if (!tmp)
return NULL;
-frame->side_data = tmp;
+*sd = tmp;
ret = av_mallocz(sizeof(*ret));
if (!ret)
@@ -706,11 +706,20 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame
*frame,
ret->size = buf->size;
ret->type = type;
-frame->side_data[frame->nb_side_data++] = ret;
+(*sd)[(*nb_sd)++] = ret;
return ret;
}
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
+{
+return
+add_side_data_to_set_from_buf(>side_data, >nb_side_data,
+ type, buf);
+}
+
AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
enum AVFrameSideDataType type,
size_t size)
--
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 v8 02/14] avutil/frame: add helper for freeing arrays of side data
---
libavutil/frame.c | 5 +
libavutil/frame.h | 11 +++
2 files changed, 16 insertions(+)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index ab425b2235..baac0706db 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -78,6 +78,11 @@ static void frame_side_data_wipe(AVFrame *frame)
wipe_side_data(>side_data, >nb_side_data);
}
+void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd)
+{
+wipe_side_data(sd, nb_sd);
+}
+
AVFrame *av_frame_alloc(void)
{
AVFrame *frame = av_malloc(sizeof(*frame));
diff --git a/libavutil/frame.h b/libavutil/frame.h
index b94687941d..27281c168f 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -988,6 +988,17 @@ int av_frame_apply_cropping(AVFrame *frame, int flags);
*/
const char *av_frame_side_data_name(enum AVFrameSideDataType type);
+/**
+ * Free all side data entries and their contents, then zeroes out the
+ * values which the pointers are pointing to.
+ *
+ * @param sdpointer to array of side data to free. Will be set to NULL
+ * upon return.
+ * @param nb_sd pointer to an integer containing the number of entries in
+ * the array. Will be set to 0 upon return.
+ */
+void av_frame_side_data_free(AVFrameSideData ***sd, int *nb_sd);
+
/**
* @}
*/
--
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 v8 01/14] avutil/frame: split side data list wiping out to non-AVFrame function
This will make it possible to to reuse logic in further commits.
---
libavutil/frame.c | 23 ++-
1 file changed, 14 insertions(+), 9 deletions(-)
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 079cf6595b..ab425b2235 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -63,14 +63,19 @@ static void free_side_data(AVFrameSideData **ptr_sd)
av_freep(ptr_sd);
}
-static void wipe_side_data(AVFrame *frame)
+static void wipe_side_data(AVFrameSideData ***sd, int *nb_side_data)
{
-for (int i = 0; i < frame->nb_side_data; i++) {
-free_side_data(>side_data[i]);
+for (int i = 0; i < *nb_side_data; i++) {
+free_side_data(&((*sd)[i]));
}
-frame->nb_side_data = 0;
+*nb_side_data = 0;
+
+av_freep(sd);
+}
-av_freep(>side_data);
+static void frame_side_data_wipe(AVFrame *frame)
+{
+wipe_side_data(>side_data, >nb_side_data);
}
AVFrame *av_frame_alloc(void)
@@ -288,7 +293,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
sd_dst = av_frame_new_side_data(dst, sd_src->type,
sd_src->size);
if (!sd_dst) {
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
return AVERROR(ENOMEM);
}
memcpy(sd_dst->data, sd_src->data, sd_src->size);
@@ -297,7 +302,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
if (!sd_dst) {
av_buffer_unref();
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
return AVERROR(ENOMEM);
}
}
@@ -437,7 +442,7 @@ int av_frame_replace(AVFrame *dst, const AVFrame *src)
if (ret < 0)
goto fail;
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
av_dict_free(>metadata);
ret = frame_copy_props(dst, src, 0);
if (ret < 0)
@@ -536,7 +541,7 @@ void av_frame_unref(AVFrame *frame)
if (!frame)
return;
-wipe_side_data(frame);
+frame_side_data_wipe(frame);
for (int i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++)
av_buffer_unref(>buf[i]);
--
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 v8 00/14] encoder AVCodecContext configuration side data
Differences to v7:
1. rebased on top of current master
2. Applied various review comments.
Comparison URL (mostly configure and wrappers, avutil/frame.c):
https://github.com/jeeb/ffmpeg/compare/avcodec_cll_mdcv_side_data_v7..avcodec_cll_mdcv_side_data_v8
This patch set I've now been working for a while since I felt like it was weird
we couldn't pass through information such as static HDR metadata to encoders
from decoded input. This initial version adds the necessary framework, as well
as adds static HDR metadata support for libsvtav1, libx264 as well as libx265
wrappers.
An alternative to this would be to make encoders only properly initialize when
they receive the first AVFrame, but that seems to be a bigger, nastier change
than introducing an AVFrameSideDataSet in avctx as everything seems to
presume that extradata etc are available after opening the encoder.
Note: Any opinions on whether FFCodec or AVCodec should have
handled_side_data list, so that if format specific generic logic is
added, it could be checked whether the codec itself handles this side
data? This could also be utilized to list handled side data from f.ex.
`ffmpeg -h encoder=libsvtav1`.
Jan
Jan Ekström (14):
avutil/frame: split side data list wiping out to non-AVFrame function
avutil/frame: add helper for freeing arrays of side data
avutil/frame: split side_data_from_buf to base and AVFrame func
avutil/frame: split side data removal out to non-AVFrame function
avutil/frame: add helper for adding side data to array
avutil/frame: add helper for adding existing side data to array
avutil/frame: add helper for adding side data w/ AVBufferRef to array
avutil/frame: add helper for getting side data from array
avcodec: add frame side data array to AVCodecContext
avcodec: add helper for configuring AVCodecContext's frame side data
ffmpeg: pass first video AVFrame's side data to encoder
avcodec/libsvtav1: add support for writing out CLL and MDCV
avcodec/libx264: add support for writing out CLL and MDCV
avcodec/libx265: add support for writing out CLL and MDCV
configure | 2 +
fftools/ffmpeg_enc.c| 10 ++
libavcodec/avcodec.c| 30 ++
libavcodec/avcodec.h| 29 +
libavcodec/libsvtav1.c | 68
libavcodec/libx264.c| 79 ++
libavcodec/libx265.c| 88
libavcodec/options.c| 2 +
libavutil/Makefile | 1 +
libavutil/frame.c | 180 ++--
libavutil/frame.h | 88
libavutil/tests/side_data_set.c | 103 ++
tests/fate/enc_external.mak | 15 +++
tests/fate/libavutil.mak| 4 +
tests/ref/fate/libsvtav1-hdr10 | 14 +++
tests/ref/fate/libx264-hdr10| 15 +++
tests/ref/fate/libx265-hdr10| 16 +++
tests/ref/fate/side_data_set| 14 +++
18 files changed, 728 insertions(+), 30 deletions(-)
create mode 100644 libavutil/tests/side_data_set.c
create mode 100644 tests/ref/fate/libsvtav1-hdr10
create mode 100644 tests/ref/fate/libx264-hdr10
create mode 100644 tests/ref/fate/libx265-hdr10
create mode 100644 tests/ref/fate/side_data_set
Full diff based on the same base hash for v7->v8:
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index e39ba05b3b..5ec6ee17de 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -248,7 +248,7 @@ int enc_open(void *opaque, const AVFrame *frame)
ret = avcodec_configure_side_data(
enc_ctx,
(const AVFrameSideData **)frame->side_data, frame->nb_side_data,
-AV_FRAME_SIDE_DATA_SET_FLAG_NO_DUPLICATES);
+AV_FRAME_SIDE_DATA_FLAG_UNIQUE);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "failed to configure video encoder:
%s!\n",
av_err2str(ret));
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index f8df3137e0..0ced87b946 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -705,7 +705,7 @@ int avcodec_configure_side_data(AVCodecContext *avctx,
return AVERROR(EINVAL);
for (int i = 0; i < nb_sd; i++) {
-int ret = av_frame_side_data_from_sd(
+int ret = av_frame_side_data_clone(
>frame_side_data, >nb_frame_side_data, sd[i], flags);
if (ret < 0) {
av_frame_side_data_free(
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 460452d591..6de4dc0f7b 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3076,7 +3076,7 @@ void av_fast_padded_mallocz(void *ptr, unsigned int
*size, size_t min_size);
int avcodec_is_open(AVCodecContext *s);
/**
- * Add multiple side data entries to an AVCodecContext set in one go, for
+ * Add multiple side data entries to an AVCodecContext's array in one go, for
* example from an AVFrame.
*
* In case the function fails to add a side data entry,
Re: [FFmpeg-devel] [PATCH] doc/fate: advise on --assert-level=2
On Mon, Mar 11, 2024 at 11:16:06AM +0100, Nicolas Gaullier wrote:
> Signed-off-by: Nicolas Gaullier
> ---
> doc/fate.texi | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/fate.texi b/doc/fate.texi
> index 2fa8c34c2d..2fa7c70251 100644
> --- a/doc/fate.texi
> +++ b/doc/fate.texi
> @@ -79,6 +79,13 @@ 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
This (or some other appropriate place in the docs)
should mention that doing so could have a performance impact
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the outpu
On 11 Mar 2024, at 15:26, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> 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
Re: [FFmpeg-devel] [PATCH] avformat/webvttdec: Skip more parts of header to let parsing continue
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 Thanks! -- /Kristoffer Brånemyr ___ 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 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 change av_ts_make_time_string() because this
problem affect all detection filters, not only silencedetect. So fixing
it in
[FFmpeg-devel] [PATCH] lavc/vvc: AVERROR_PATCHWELCOME for subpictures
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(+)
diff --git a/libavcodec/vvc/vvc_ps.c b/libavcodec/vvc/vvc_ps.c
index e6e46d2039..62515a6343 100644
--- a/libavcodec/vvc/vvc_ps.c
+++ b/libavcodec/vvc/vvc_ps.c
@@ -72,6 +72,18 @@ static int sps_map_pixel_format(VVCSPS *sps, void *log_ctx)
return 0;
}
+static int sps_subpic_info(VVCSPS *sps, void *log_ctx)
+{
+const H266RawSPS *r = sps->r;
+
+if (r->sps_num_subpics_minus1 > 0) {
+avpriv_report_missing_feature(log_ctx, "Subpictures");
+return AVERROR_PATCHWELCOME;
+}
+
+return 0;
+}
+
static int sps_bit_depth(VVCSPS *sps, void *log_ctx)
{
const H266RawSPS *r = sps->r;
@@ -177,6 +189,9 @@ static int sps_derive(VVCSPS *sps, void *log_ctx)
int ret;
const H266RawSPS *r = sps->r;
+ret = sps_subpic_info(sps, log_ctx);
+if (ret < 0)
+return ret;
ret = sps_bit_depth(sps, log_ctx);
if (ret < 0)
return ret;
--
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] Maintaining email threads for patch submissions using git send-email
On 3/11/2024 2:44 PM, Allan Cady via ffmpeg-devel wrote: Could someone please have a look at an issue I'm having in resubmitting a patch, trying to get the resubmission email to appear as a reply on an existing thread? In order to conform to submission guidelines in ffmpeg-devel, I'm using git format-patch and git send-email, using the --in-reply-to option, but it's not giving the expected results. I had started a thread in this mailing list for a patch I've been working on. I had gotten some comments to my initial submission, worked on addressing them, and last night I submitted it again. I wanted the resubmission to appear as a reply on the earlier thread, to preserve that conversation. After configuring git to use the same email account that I had used for the earlier submissions and comments, I used the following git command: git send-email --to=ffmpeg-devel@ffmpeg.org --in-reply-to="e4d3f14f-ac69-9424-804e-ee5025059...@passwd.hu" I got the message ID from the following line in the message I wanted to reply to: Message-ID: But when I submitted the patch, it showed up in the list as a reply on a completely different, unrelated thread. They at least show up in my client as replies alright. ___ 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] Maintaining email threads for patch submissions using git send-email
Could someone please have a look at an issue I'm having in resubmitting a patch, trying to get the resubmission email to appear as a reply on an existing thread? In order to conform to submission guidelines in ffmpeg-devel, I'm using git format-patch and git send-email, using the --in-reply-to option, but it's not giving the expected results. I had started a thread in this mailing list for a patch I've been working on. I had gotten some comments to my initial submission, worked on addressing them, and last night I submitted it again. I wanted the resubmission to appear as a reply on the earlier thread, to preserve that conversation. After configuring git to use the same email account that I had used for the earlier submissions and comments, I used the following git command: git send-email --to=ffmpeg-devel@ffmpeg.org --in-reply-to="e4d3f14f-ac69-9424-804e-ee5025059...@passwd.hu" I got the message ID from the following line in the message I wanted to reply to: Message-ID: But when I submitted the patch, it showed up in the list as a reply on a completely different, unrelated thread. So I came back and fixed a couple other issues in the patch (I had messed up the subject line), double-checked that I had copied the Message-ID, and entered this command (adding angle brackets this time to the ID, just in case that might matter). git send-email --to=ffmpeg-devel@ffmpeg.org --in-reply-to="" Still, the message went to the same incorrect thread. Is there possibly something else I need to add to the send-email command to get it to attach to the older thread? Thanks, Allan ___ 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/4] avocdec/ass: simplify linebreaks
LGTM. sha256 sum of my sample is bit-identical
ab6d14ea8b6ce04f3dd57c0be03bc34a064c9babe439d3882a0797f12c4e9d40
TEST_ATSC.cc.ass
ab6d14ea8b6ce04f3dd57c0be03bc34a064c9babe439d3882a0797f12c4e9d40
TEST_ATSC_SimplifyLinebreaks.cc.ass
On Sun, Feb 11, 2024 at 8:02 PM Oneric wrote:
> ff_ass_subtitle_header_* still used explicit CRLF linebreaks
> eventhough they will get normalised to LF later since commit
> 7bf1b9b35769b37684dd2f18a54f01d852a540c8. Just directly use LF.
> ---
> libavcodec/ass.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/libavcodec/ass.c b/libavcodec/ass.c
> index e7a1ac0eb5..927b801404 100644
> --- a/libavcodec/ass.c
> +++ b/libavcodec/ass.c
> @@ -35,15 +35,15 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
> int border_style, int alignment)
> {
> avctx->subtitle_header = av_asprintf(
> - "[Script Info]\r\n"
> - "; Script generated by FFmpeg/Lavc%s\r\n"
> - "ScriptType: v4.00+\r\n"
> - "PlayResX: %d\r\n"
> - "PlayResY: %d\r\n"
> - "ScaledBorderAndShadow: yes\r\n"
> - "YCbCr Matrix: None\r\n"
> - "\r\n"
> - "[V4+ Styles]\r\n"
> + "[Script Info]\n"
> + "; Script generated by FFmpeg/Lavc%s\n"
> + "ScriptType: v4.00+\n"
> + "PlayResX: %d\n"
> + "PlayResY: %d\n"
> + "ScaledBorderAndShadow: yes\n"
> + "YCbCr Matrix: None\n"
> + "\n"
> + "[V4+ Styles]\n"
>
> /* ASS (v4+) header */
> "Format: Name, "
> @@ -54,7 +54,7 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
> "Spacing, Angle, "
> "BorderStyle, Outline, Shadow, "
> "Alignment, MarginL, MarginR, MarginV, "
> - "Encoding\r\n"
> + "Encoding\n"
>
> "Style: "
> "Default," /* Name */
> @@ -65,11 +65,11 @@ int ff_ass_subtitle_header_full(AVCodecContext *avctx,
> "0,0," /* Spacing, Angle */
> "%d,1,0," /* BorderStyle, Outline, Shadow */
> "%d,10,10,10," /* Alignment, Margin[LRV] */
> - "1\r\n"/* Encoding */
> + "1\n" /* Encoding */
>
> - "\r\n"
> - "[Events]\r\n"
> - "Format: Layer, Start, End, Style, Name, MarginL, MarginR,
> MarginV, Effect, Text\r\n",
> + "\n"
> + "[Events]\n"
> + "Format: Layer, Start, End, Style, Name, MarginL, MarginR,
> MarginV, Effect, Text\n",
> !(avctx->flags & AV_CODEC_FLAG_BITEXACT) ?
> AV_STRINGIFY(LIBAVCODEC_VERSION) : "",
> play_res_x, play_res_y, font, font_size,
> primary_color, secondary_color, outline_color, back_color,
> --
> 2.39.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 v2] avcodec/ccaption_dec: honor transparency of leading non-breaking space
On date Sunday 2024-03-10 19:44:11 -0500, Marth64 wrote:
> In Closed Captions (US), the non-breaking space (0xA0) can be used to align
> text horizontally from the left by using it 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 over 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.
>
> v2 only updates the commit message which mistakenly referenced avformat.
>
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
> index faf058ce97..591013d202 100644
> --- a/libavcodec/ccaption_dec.c
> +++ b/libavcodec/ccaption_dec.c
> @@ -91,7 +91,7 @@ enum cc_charset {
> ENTRY(0x36, "\u00a3")\
> ENTRY(0x37, "\u266a")\
> ENTRY(0x38, "\u00e0")\
> -ENTRY(0x39, "\u00A0")\
> +ENTRY(0x39, "\u00a0")\
> ENTRY(0x3a, "\u00e8")\
> ENTRY(0x3b, "\u00e2")\
> ENTRY(0x3c, "\u00ea")\
> @@ -471,7 +471,8 @@ static int capture_screen(CCaptionSubContext *ctx)
> const char *row = screen->characters[i];
> const char *charset = screen->charsets[i];
> j = 0;
> -while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN)
> +while ((row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN) ||
> + (row[j] == 0x39 && charset[j] == CCSET_SPECIAL_AMERICAN))
> j++;
> if (!tab || j < tab)
> tab = j;
> @@ -491,7 +492,9 @@ static int capture_screen(CCaptionSubContext *ctx)
> j = 0;
>
> /* skip leading space */
> -while (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN && j
> < tab)
> +while (j < tab &&
> + (row[j] == ' ' && charset[j] == CCSET_BASIC_AMERICAN) ||
> + (row[j] == 0x39 && charset[j] == CCSET_SPECIAL_AMERICAN))
> j++;
Patch LGTM, will apply the complete patcheset if I see no comments
after a few days.
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
LGTM from readability perspective. Nice catch on the command missing slash.
On Mon, Mar 11, 2024 at 11:15 AM Stefano Sabatini
wrote:
> ---
> doc/muxers.texi | 138 ++--
> 1 file changed, 74 insertions(+), 64 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 2104cc4a95..34de187f5e 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1421,104 +1421,114 @@ ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r
> 29.97 -ac 2 -ar 48000 -y out.dv
>
> @anchor{fifo}
> @section fifo
> +FIFO (First-In First-Out) muxer.
>
> -The fifo pseudo-muxer allows the separation of encoding and muxing by
> using
> -first-in-first-out queue and running the actual muxer in a separate
> thread. This
> -is especially useful in combination with the @ref{tee} muxer and can be
> used to
> -send data to several destinations with different reliability/writing
> speed/latency.
> +The @samp{fifo} pseudo-muxer allows the separation of encoding and
> +muxing by using a first-in-first-out queue and running the actual muxer
> +in a separate thread.
>
> -API users should be aware that callback functions (interrupt_callback,
> -io_open and io_close) used within its AVFormatContext must be thread-safe.
> +This is especially useful in combination with
> +the @ref{tee} muxer and can be used to send data to several
> +destinations with different reliability/writing speed/latency.
>
> -The behavior of the fifo muxer if the queue fills up or if the output
> fails is
> -selectable,
> +The target muxer is either selected from the output name or specified
> +through the @option{fifo_format} option.
>
> +The behavior of the @samp{fifo} muxer if the queue fills up or if the
> +output fails (e.g. if a packet cannot be written to the output) is
> +selectable:
> @itemize @bullet
> -
> @item
> -output can be transparently restarted with configurable delay between
> retries
> -based on real time or time of the processed stream.
> +Output can be transparently restarted with configurable delay between
> +retries based on real time or time of the processed stream.
>
> @item
> -encoding can be blocked during temporary failure, or continue
> transparently
> -dropping packets in case fifo queue fills up.
> -
> +Encoding can be blocked during temporary failure, or continue
> transparently
> +dropping packets in case the FIFO queue fills up.
> @end itemize
>
> +API users should be aware that callback functions
> +(@code{interrupt_callback}, @code{io_open} and @code{io_close}) used
> +within its @code{AVFormatContext} must be thread-safe.
> +
> +@subsection Options
> @table @option
>
> -@item fifo_format
> +@item attempt_recovery @var{bool}
> +If failure occurs, attempt to recover the output. This is especially
> +useful when used with network output, since it makes it possible to
> +restart streaming transparently. By default this option is set to
> +@code{false}.
> +
> +@item drop_pkts_on_overflow @var{bool}
> +If set to @code{true}, in case the fifo queue fills up, packets will
> +be dropped rather than blocking the encoder. This makes it possible to
> +continue streaming without delaying the input, at the cost of omitting
> +part of the stream. By default this option is set to @code{false}, so in
> +such cases the encoder will be blocked until the muxer processes some
> +of the packets and none of them is lost.
> +
> +@item fifo_format @var{format_name}
> Specify the format name. Useful if it cannot be guessed from the
> output name suffix.
>
> -@item queue_size
> -Specify size of the queue (number of packets). Default value is 60.
> +@item format_opts @var{options}
> +Specify format options for the underlying muxer. Muxer options can be
> +specified as a list of @var{key}=@var{value} pairs separated by ':'.
>
> -@item format_opts
> -Specify format options for the underlying muxer. Muxer options can be
> specified
> -as a list of @var{key}=@var{value} pairs separated by ':'.
> +@item max_recovery_attempts @var{count}
> +Set maximum number of successive unsuccessful recovery attempts after
> +which the output fails permanently. By default this option is set to
> +@code{0} (unlimited).
>
> -@item drop_pkts_on_overflow @var{bool}
> -If set to 1 (true), in case the fifo queue fills up, packets will be
> dropped
> -rather than blocking the encoder. This makes it possible to continue
> streaming without
> -delaying the input, at the cost of omitting part of the stream. By default
> -this option is set to 0 (false), so in such cases the encoder will be
> blocked
> -until the muxer processes some of the packets and none of them is lost.
> +@item queue_size @var{size}
> +Specify size of the queue as a number of packets. Default value is
> +@code{60}.
>
> -@item attempt_recovery @var{bool}
> -If failure occurs, attempt to recover the output. This is especially
> useful
> -when used with network output, since it makes it possible to restart
> streaming transparently.
> -By default this option is
Re: [FFmpeg-devel] [PATCH 1/3] lavf/fifo: sort options by name
LGTM. Options before are the same as after change.
On Mon, Mar 11, 2024 at 11:15 AM Stefano Sabatini
wrote:
> ---
> libavformat/fifo.c | 28 ++--
> 1 file changed, 14 insertions(+), 14 deletions(-)
>
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index 074a46485c..a3d41ba0d3 100644
> --- a/libavformat/fifo.c
> +++ b/libavformat/fifo.c
> @@ -663,36 +663,36 @@ static void fifo_deinit(AVFormatContext *avf)
>
> #define OFFSET(x) offsetof(FifoContext, x)
> static const AVOption options[] = {
> -{"fifo_format", "Target muxer", OFFSET(format),
> - AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,
> AV_OPT_FLAG_ENCODING_PARAM},
> -
> -{"queue_size", "Size of fifo queue", OFFSET(queue_size),
> - AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
> AV_OPT_FLAG_ENCODING_PARAM},
> -
> -{"format_opts", "Options to be passed to underlying muxer",
> OFFSET(format_options),
> - AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0,
> AV_OPT_FLAG_ENCODING_PARAM},
> +{"attempt_recovery", "Attempt recovery in case of failure",
> OFFSET(attempt_recovery),
> +AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>
> {"drop_pkts_on_overflow", "Drop packets on fifo queue overflow
> not to block encoder", OFFSET(drop_pkts_on_overflow),
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>
> -{"restart_with_keyframe", "Wait for keyframe when restarting
> output", OFFSET(restart_with_keyframe),
> - AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
> +{"fifo_format", "Target muxer", OFFSET(format),
> + AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,
> AV_OPT_FLAG_ENCODING_PARAM},
>
> -{"attempt_recovery", "Attempt recovery in case of failure",
> OFFSET(attempt_recovery),
> -AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
> +{"format_opts", "Options to be passed to underlying muxer",
> OFFSET(format_options),
> + AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0,
> AV_OPT_FLAG_ENCODING_PARAM},
>
> {"max_recovery_attempts", "Maximal number of recovery attempts",
> OFFSET(max_recovery_attempts),
> AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_MAX_RECOVERY_ATTEMPTS}, 0,
> INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
>
> -{"recovery_wait_time", "Waiting time between recovery attempts",
> OFFSET(recovery_wait_time),
> - AV_OPT_TYPE_DURATION, {.i64 =
> FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC}, 0, INT64_MAX,
> AV_OPT_FLAG_ENCODING_PARAM},
> +{"queue_size", "Size of fifo queue", OFFSET(queue_size),
> + AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
> AV_OPT_FLAG_ENCODING_PARAM},
>
> {"recovery_wait_streamtime", "Use stream time instead of real
> time while waiting for recovery",
> OFFSET(recovery_wait_streamtime), AV_OPT_TYPE_BOOL, {.i64 = 0},
> 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>
> +{"recovery_wait_time", "Waiting time between recovery attempts",
> OFFSET(recovery_wait_time),
> + AV_OPT_TYPE_DURATION, {.i64 =
> FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC}, 0, INT64_MAX,
> AV_OPT_FLAG_ENCODING_PARAM},
> +
> {"recover_any_error", "Attempt recovery regardless of type of the
> error", OFFSET(recover_any_error),
> AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
>
> +{"restart_with_keyframe", "Wait for keyframe when restarting
> output", OFFSET(restart_with_keyframe),
> + AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
> +
> {"timeshift", "Delay fifo output", OFFSET(timeshift),
> AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX,
> AV_OPT_FLAG_ENCODING_PARAM},
>
> --
> 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] avcodec/ccaption_dec: don't print multiple \pos tags per cue
On date Sunday 2024-03-10 19:40:47 -0500, Marth64 wrote:
> Currently, Closed Captions decoder prints multiple \pos ASS tags per line,
> per cue. This is invalid behavior, because only the first \pos tag in a cue
> is honored by ASS anyway. Don't write multiple \pos tags.
>
> Signed-off-by: Marth64
> ---
> libavcodec/ccaption_dec.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 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(>buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x, y);
> +
> +if (!seen_row) {
> +av_bprintf(>buffer[bidx], "{\\an7}{\\pos(%d,%d)}", x,
> y);
> +seen_row = 1;
> +}
>
> for (; j < SCREEN_COLUMNS; j++) {
> const char *e_tag = "", *s_tag = "", *c_tag = "", *b_tag =
> "";
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] avcodec/mpeg12dec: extract only one type of CC substream
On date Sunday 2024-03-10 19:18:56 -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.
>
> In tandem, I am working on an improvement to src_movie to allow passing
> decoder
> options (as src_movie via lavfi is the "de facto" way to extract CCs right
> now).
> This way, users can realize the newly added option.
>
> Signed-off-by: Marth64
> ---
> libavcodec/mpeg12dec.c | 49 +++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 3a2f17e508..a42e1c661f 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;
> @@ -1908,7 +1916,8 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
> {
> 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 +1936,15 @@ 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;
> +
> +if (!s1->cc_format) {
> +s1->cc_format = CC_FORMAT_A53_PART4;
> +av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is A53
> format\n");
> +}
> }
> 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;
> @@ -1974,9 +1989,15 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
> }
> }
> avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> +
> +if (!s1->cc_format) {
> +s1->cc_format = CC_FORMAT_SCTE20;
> +av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is
> SCTE-20 format\n");
> +}
> }
> 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
> *
> @@ -2034,6 +2055,11 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
> }
> }
> avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
> +
> +if (!s1->cc_format) {
> +s1->cc_format = CC_FORMAT_DVD;
> +av_log(avctx, AV_LOG_DEBUG, "CC: first seen substream is DVD
> format\n");
> +}
nit: probably this might be factorized, either with a function or a
macro
> }
> return 1;
> }
> @@ -2598,11 +2624,28 @@ 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 (0=auto)",
> M2V_OFFSET(cc_format), AV_OPT_TYPE_INT, { .i64 = 0 }, CC_FORMAT_AUTO,
>
[FFmpeg-devel] [PATCH 3/3] doc/muxers/fifo: review documentation
---
doc/muxers.texi | 138 ++--
1 file changed, 74 insertions(+), 64 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..34de187f5e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1421,104 +1421,114 @@ ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r
29.97 -ac 2 -ar 48000 -y out.dv
@anchor{fifo}
@section fifo
+FIFO (First-In First-Out) muxer.
-The fifo pseudo-muxer allows the separation of encoding and muxing by using
-first-in-first-out queue and running the actual muxer in a separate thread.
This
-is especially useful in combination with the @ref{tee} muxer and can be used to
-send data to several destinations with different reliability/writing
speed/latency.
+The @samp{fifo} pseudo-muxer allows the separation of encoding and
+muxing by using a first-in-first-out queue and running the actual muxer
+in a separate thread.
-API users should be aware that callback functions (interrupt_callback,
-io_open and io_close) used within its AVFormatContext must be thread-safe.
+This is especially useful in combination with
+the @ref{tee} muxer and can be used to send data to several
+destinations with different reliability/writing speed/latency.
-The behavior of the fifo muxer if the queue fills up or if the output fails is
-selectable,
+The target muxer is either selected from the output name or specified
+through the @option{fifo_format} option.
+The behavior of the @samp{fifo} muxer if the queue fills up or if the
+output fails (e.g. if a packet cannot be written to the output) is
+selectable:
@itemize @bullet
-
@item
-output can be transparently restarted with configurable delay between retries
-based on real time or time of the processed stream.
+Output can be transparently restarted with configurable delay between
+retries based on real time or time of the processed stream.
@item
-encoding can be blocked during temporary failure, or continue transparently
-dropping packets in case fifo queue fills up.
-
+Encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case the FIFO queue fills up.
@end itemize
+API users should be aware that callback functions
+(@code{interrupt_callback}, @code{io_open} and @code{io_close}) used
+within its @code{AVFormatContext} must be thread-safe.
+
+@subsection Options
@table @option
-@item fifo_format
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially
+useful when used with network output, since it makes it possible to
+restart streaming transparently. By default this option is set to
+@code{false}.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to @code{true}, in case the fifo queue fills up, packets will
+be dropped rather than blocking the encoder. This makes it possible to
+continue streaming without delaying the input, at the cost of omitting
+part of the stream. By default this option is set to @code{false}, so in
+such cases the encoder will be blocked until the muxer processes some
+of the packets and none of them is lost.
+
+@item fifo_format @var{format_name}
Specify the format name. Useful if it cannot be guessed from the
output name suffix.
-@item queue_size
-Specify size of the queue (number of packets). Default value is 60.
+@item format_opts @var{options}
+Specify format options for the underlying muxer. Muxer options can be
+specified as a list of @var{key}=@var{value} pairs separated by ':'.
-@item format_opts
-Specify format options for the underlying muxer. Muxer options can be specified
-as a list of @var{key}=@var{value} pairs separated by ':'.
+@item max_recovery_attempts @var{count}
+Set maximum number of successive unsuccessful recovery attempts after
+which the output fails permanently. By default this option is set to
+@code{0} (unlimited).
-@item drop_pkts_on_overflow @var{bool}
-If set to 1 (true), in case the fifo queue fills up, packets will be dropped
-rather than blocking the encoder. This makes it possible to continue streaming
without
-delaying the input, at the cost of omitting part of the stream. By default
-this option is set to 0 (false), so in such cases the encoder will be blocked
-until the muxer processes some of the packets and none of them is lost.
+@item queue_size @var{size}
+Specify size of the queue as a number of packets. Default value is
+@code{60}.
-@item attempt_recovery @var{bool}
-If failure occurs, attempt to recover the output. This is especially useful
-when used with network output, since it makes it possible to restart streaming
transparently.
-By default this option is set to 0 (false).
+@item recover_any_error @var{bool}
+If set to @code{true}, recovery will be attempted regardless of type
+of the error causing the failure. By default this option is set to
+@code{false} and in case of certain (usually permanent) errors the
+recovery is not attempted even when the @option{attempt_recovery}
+option is set to
[FFmpeg-devel] [PATCH 2/3] lavf/fifo: fix check on last_recovery_ts
Correct check on PTS nullness.
---
libavformat/fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index a3d41ba0d3..fcd80f217a 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -345,7 +345,7 @@ static int fifo_thread_attempt_recovery(FifoThreadContext
*ctx, FifoMessage *msg
AV_NOPTS_VALUE : 0;
} else {
if (fifo->recovery_wait_streamtime) {
-if (ctx->last_recovery_ts == AV_NOPTS_VALUE) {
+if (ctx->last_recovery_ts != AV_NOPTS_VALUE) {
AVRational tb = avf->streams[pkt->stream_index]->time_base;
time_since_recovery = av_rescale_q(pkt->pts -
ctx->last_recovery_ts,
tb, AV_TIME_BASE_Q);
--
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: sort options by name
---
libavformat/fifo.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 074a46485c..a3d41ba0d3 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -663,36 +663,36 @@ static void fifo_deinit(AVFormatContext *avf)
#define OFFSET(x) offsetof(FifoContext, x)
static const AVOption options[] = {
-{"fifo_format", "Target muxer", OFFSET(format),
- AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
-
-{"queue_size", "Size of fifo queue", OFFSET(queue_size),
- AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
-
-{"format_opts", "Options to be passed to underlying muxer",
OFFSET(format_options),
- AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
+{"attempt_recovery", "Attempt recovery in case of failure",
OFFSET(attempt_recovery),
+AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{"drop_pkts_on_overflow", "Drop packets on fifo queue overflow not to
block encoder", OFFSET(drop_pkts_on_overflow),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
-{"restart_with_keyframe", "Wait for keyframe when restarting output",
OFFSET(restart_with_keyframe),
- AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"fifo_format", "Target muxer", OFFSET(format),
+ AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
-{"attempt_recovery", "Attempt recovery in case of failure",
OFFSET(attempt_recovery),
-AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"format_opts", "Options to be passed to underlying muxer",
OFFSET(format_options),
+ AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
{"max_recovery_attempts", "Maximal number of recovery attempts",
OFFSET(max_recovery_attempts),
AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_MAX_RECOVERY_ATTEMPTS}, 0,
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
-{"recovery_wait_time", "Waiting time between recovery attempts",
OFFSET(recovery_wait_time),
- AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC},
0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+{"queue_size", "Size of fifo queue", OFFSET(queue_size),
+ AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
{"recovery_wait_streamtime", "Use stream time instead of real time
while waiting for recovery",
OFFSET(recovery_wait_streamtime), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
AV_OPT_FLAG_ENCODING_PARAM},
+{"recovery_wait_time", "Waiting time between recovery attempts",
OFFSET(recovery_wait_time),
+ AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC},
0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+
{"recover_any_error", "Attempt recovery regardless of type of the
error", OFFSET(recover_any_error),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"restart_with_keyframe", "Wait for keyframe when restarting output",
OFFSET(restart_with_keyframe),
+ AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+
{"timeshift", "Delay fifo output", OFFSET(timeshift),
AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
--
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/fifo: review documentation
---
doc/muxers.texi | 138 ++--
1 file changed, 74 insertions(+), 64 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2104cc4a95..34de187f5e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1421,104 +1421,114 @@ ffmpeg -i INPUT -s:v 720x480 -pix_fmt yuv411p -r
29.97 -ac 2 -ar 48000 -y out.dv
@anchor{fifo}
@section fifo
+FIFO (First-In First-Out) muxer.
-The fifo pseudo-muxer allows the separation of encoding and muxing by using
-first-in-first-out queue and running the actual muxer in a separate thread.
This
-is especially useful in combination with the @ref{tee} muxer and can be used to
-send data to several destinations with different reliability/writing
speed/latency.
+The @samp{fifo} pseudo-muxer allows the separation of encoding and
+muxing by using a first-in-first-out queue and running the actual muxer
+in a separate thread.
-API users should be aware that callback functions (interrupt_callback,
-io_open and io_close) used within its AVFormatContext must be thread-safe.
+This is especially useful in combination with
+the @ref{tee} muxer and can be used to send data to several
+destinations with different reliability/writing speed/latency.
-The behavior of the fifo muxer if the queue fills up or if the output fails is
-selectable,
+The target muxer is either selected from the output name or specified
+through the @option{fifo_format} option.
+The behavior of the @samp{fifo} muxer if the queue fills up or if the
+output fails (e.g. if a packet cannot be written to the output) is
+selectable:
@itemize @bullet
-
@item
-output can be transparently restarted with configurable delay between retries
-based on real time or time of the processed stream.
+Output can be transparently restarted with configurable delay between
+retries based on real time or time of the processed stream.
@item
-encoding can be blocked during temporary failure, or continue transparently
-dropping packets in case fifo queue fills up.
-
+Encoding can be blocked during temporary failure, or continue transparently
+dropping packets in case the FIFO queue fills up.
@end itemize
+API users should be aware that callback functions
+(@code{interrupt_callback}, @code{io_open} and @code{io_close}) used
+within its @code{AVFormatContext} must be thread-safe.
+
+@subsection Options
@table @option
-@item fifo_format
+@item attempt_recovery @var{bool}
+If failure occurs, attempt to recover the output. This is especially
+useful when used with network output, since it makes it possible to
+restart streaming transparently. By default this option is set to
+@code{false}.
+
+@item drop_pkts_on_overflow @var{bool}
+If set to @code{true}, in case the fifo queue fills up, packets will
+be dropped rather than blocking the encoder. This makes it possible to
+continue streaming without delaying the input, at the cost of omitting
+part of the stream. By default this option is set to @code{false}, so in
+such cases the encoder will be blocked until the muxer processes some
+of the packets and none of them is lost.
+
+@item fifo_format @var{format_name}
Specify the format name. Useful if it cannot be guessed from the
output name suffix.
-@item queue_size
-Specify size of the queue (number of packets). Default value is 60.
+@item format_opts @var{options}
+Specify format options for the underlying muxer. Muxer options can be
+specified as a list of @var{key}=@var{value} pairs separated by ':'.
-@item format_opts
-Specify format options for the underlying muxer. Muxer options can be specified
-as a list of @var{key}=@var{value} pairs separated by ':'.
+@item max_recovery_attempts @var{count}
+Set maximum number of successive unsuccessful recovery attempts after
+which the output fails permanently. By default this option is set to
+@code{0} (unlimited).
-@item drop_pkts_on_overflow @var{bool}
-If set to 1 (true), in case the fifo queue fills up, packets will be dropped
-rather than blocking the encoder. This makes it possible to continue streaming
without
-delaying the input, at the cost of omitting part of the stream. By default
-this option is set to 0 (false), so in such cases the encoder will be blocked
-until the muxer processes some of the packets and none of them is lost.
+@item queue_size @var{size}
+Specify size of the queue as a number of packets. Default value is
+@code{60}.
-@item attempt_recovery @var{bool}
-If failure occurs, attempt to recover the output. This is especially useful
-when used with network output, since it makes it possible to restart streaming
transparently.
-By default this option is set to 0 (false).
+@item recover_any_error @var{bool}
+If set to @code{true}, recovery will be attempted regardless of type
+of the error causing the failure. By default this option is set to
+@code{false} and in case of certain (usually permanent) errors the
+recovery is not attempted even when the @option{attempt_recovery}
+option is set to
[FFmpeg-devel] [PATCH 1/3] lavf/fifo: sort options by name
---
libavformat/fifo.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index 074a46485c..a3d41ba0d3 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -663,36 +663,36 @@ static void fifo_deinit(AVFormatContext *avf)
#define OFFSET(x) offsetof(FifoContext, x)
static const AVOption options[] = {
-{"fifo_format", "Target muxer", OFFSET(format),
- AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
-
-{"queue_size", "Size of fifo queue", OFFSET(queue_size),
- AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
-
-{"format_opts", "Options to be passed to underlying muxer",
OFFSET(format_options),
- AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
+{"attempt_recovery", "Attempt recovery in case of failure",
OFFSET(attempt_recovery),
+AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
{"drop_pkts_on_overflow", "Drop packets on fifo queue overflow not to
block encoder", OFFSET(drop_pkts_on_overflow),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
-{"restart_with_keyframe", "Wait for keyframe when restarting output",
OFFSET(restart_with_keyframe),
- AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"fifo_format", "Target muxer", OFFSET(format),
+ AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
-{"attempt_recovery", "Attempt recovery in case of failure",
OFFSET(attempt_recovery),
-AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"format_opts", "Options to be passed to underlying muxer",
OFFSET(format_options),
+ AV_OPT_TYPE_DICT, {.str = NULL}, 0, 0, AV_OPT_FLAG_ENCODING_PARAM},
{"max_recovery_attempts", "Maximal number of recovery attempts",
OFFSET(max_recovery_attempts),
AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_MAX_RECOVERY_ATTEMPTS}, 0,
INT_MAX, AV_OPT_FLAG_ENCODING_PARAM},
-{"recovery_wait_time", "Waiting time between recovery attempts",
OFFSET(recovery_wait_time),
- AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC},
0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+{"queue_size", "Size of fifo queue", OFFSET(queue_size),
+ AV_OPT_TYPE_INT, {.i64 = FIFO_DEFAULT_QUEUE_SIZE}, 1, INT_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
{"recovery_wait_streamtime", "Use stream time instead of real time
while waiting for recovery",
OFFSET(recovery_wait_streamtime), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1,
AV_OPT_FLAG_ENCODING_PARAM},
+{"recovery_wait_time", "Waiting time between recovery attempts",
OFFSET(recovery_wait_time),
+ AV_OPT_TYPE_DURATION, {.i64 = FIFO_DEFAULT_RECOVERY_WAIT_TIME_USEC},
0, INT64_MAX, AV_OPT_FLAG_ENCODING_PARAM},
+
{"recover_any_error", "Attempt recovery regardless of type of the
error", OFFSET(recover_any_error),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+{"restart_with_keyframe", "Wait for keyframe when restarting output",
OFFSET(restart_with_keyframe),
+ AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, AV_OPT_FLAG_ENCODING_PARAM},
+
{"timeshift", "Delay fifo output", OFFSET(timeshift),
AV_OPT_TYPE_DURATION, {.i64 = 0}, 0, INT64_MAX,
AV_OPT_FLAG_ENCODING_PARAM},
--
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: fix check on last_recovery_ts
Correct check on PTS nullness.
---
libavformat/fifo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index a3d41ba0d3..fcd80f217a 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -345,7 +345,7 @@ static int fifo_thread_attempt_recovery(FifoThreadContext
*ctx, FifoMessage *msg
AV_NOPTS_VALUE : 0;
} else {
if (fifo->recovery_wait_streamtime) {
-if (ctx->last_recovery_ts == AV_NOPTS_VALUE) {
+if (ctx->last_recovery_ts != AV_NOPTS_VALUE) {
AVRational tb = avf->streams[pkt->stream_index]->time_base;
time_since_recovery = av_rescale_q(pkt->pts -
ctx->last_recovery_ts,
tb, AV_TIME_BASE_Q);
--
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 v3 0/1] avformat/demux: Add durationprobesize AVOption
Ping ? v3 "bis" rebased and wrapped lines in commit msg Nicolas Gaullier (1): avformat/demux: Add durationprobesize AVOption doc/APIchanges | 3 +++ doc/formats.texi| 16 +++- libavformat/avformat.h | 12 libavformat/demux.c | 13 - libavformat/options_table.h | 1 + libavformat/version.h | 2 +- 6 files changed, 40 insertions(+), 7 deletions(-) -- 2.30.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/1] avformat/demux: Add durationprobesize AVOption
Yet another probesize used to get the durations when
estimate_timings_from_pts is required. It is aimed at users interested
in better durations probing for itself, or because using
avformat_find_stream_info indirectly and requiring exact values: for
concatdec for example, especially if streamcopying above it.
The current code is a performance trade-off that can fail to get video
stream durations in a scenario with high bitrates and buffering for
files ending cleanly (as opposed to live captures): the physical gap
between the last video packet and the last audio packet is very high in
such a case.
Default behaviour is unchanged: 250k up to 250k << 6 (step by step).
Setting this new option has two effects:
- override the maximum probesize (currently 250k << 6)
- reduce the number of steps to 1 instead of 6, this is to avoid
detecting the audio "too early" and failing to reach a video packet.
Even if a single audio stream duration is found but not the other
audio/video stream durations, there will be a retry, so at the end the
full user-overriden probesize will be used as expected by the user.
Signed-off-by: Nicolas Gaullier
---
doc/APIchanges | 3 +++
doc/formats.texi| 16 +++-
libavformat/avformat.h | 12
libavformat/demux.c | 13 -
libavformat/options_table.h | 1 +
libavformat/version.h | 2 +-
6 files changed, 40 insertions(+), 7 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index cf58c8c5f0..c97acf60d1 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-03-11 - xx - lavf 61.1.100 - avformat.h
+ Add AVFormatContext.duration_probesize
+
2024-03-08 - xx - lavc 61.1.100 - avcodec.h
Add AVCodecContext.[nb_]side_data_prefer_packet.
diff --git a/doc/formats.texi b/doc/formats.texi
index 69fc1457a4..9cada03a6e 100644
--- a/doc/formats.texi
+++ b/doc/formats.texi
@@ -225,9 +225,23 @@ Specifies the maximum number of streams. This can be used
to reject files that
would require too many resources due to a large number of streams.
@item skip_estimate_duration_from_pts @var{bool} (@emph{input})
-Skip estimation of input duration when calculated using PTS.
+Skip estimation of input duration if it requires an additional probing for pts
at end of file.
At present, applicable for MPEG-PS and MPEG-TS.
+@item durationprobesize @var{integer} (@emph{input})
+Set probing size for input duration estimation when it actually requires an
additional probing
+for pts at end of file.
+At present, applicable for MPEG-PS and MPEG-TS.
+It is aimed at users interested in better durations probing for itself, or
indirectly
+for specific use cases like using the concat demuxer.
+Files with high bitrates and ending cleanly (as opposed to live captures), can
lead
+to a large physical gap between the last video packet and the last audio
packet,
+so many bytes have to be read in order to get a video stream duration.
+Setting this value has a performance impact even for small files because the
probing size is fixed.
+Default behaviour is a trade-off, largely adaptive: the probing size may range
from
+250K up to 16M, but it is not extended to get streams durations at all costs.
+Must be an integer not lesser than 1, or 0 for default behaviour.
+
@item strict, f_strict @var{integer} (@emph{input/output})
Specify how strictly to follow the standards. @code{f_strict} is deprecated and
should be used only via the @command{ffmpeg} tool.
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index de40397676..9042a62b70 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1667,6 +1667,8 @@ typedef struct AVFormatContext {
* Skip duration calcuation in estimate_timings_from_pts.
* - encoding: unused
* - decoding: set by user
+ *
+ * @sa duration_probesize
*/
int skip_estimate_duration_from_pts;
@@ -1870,6 +1872,16 @@ typedef struct AVFormatContext {
* @return 0 on success, a negative AVERROR code on failure
*/
int (*io_close2)(struct AVFormatContext *s, AVIOContext *pb);
+
+/**
+ * Maximum number of bytes read from input in order to determine stream
durations
+ * when using estimate_timings_from_pts in avformat_find_stream_info().
+ * Demuxing only, set by the caller before avformat_find_stream_info().
+ * Can be set to 0 to let avformat choose using a heuristic.
+ *
+ * @sa skip_estimate_duration_from_pts
+ */
+int64_t duration_probesize;
} AVFormatContext;
/**
diff --git a/libavformat/demux.c b/libavformat/demux.c
index 4c50eb5568..68b0c51720 100644
--- a/libavformat/demux.c
+++ b/libavformat/demux.c
@@ -1817,8 +1817,9 @@ static void
estimate_timings_from_bit_rate(AVFormatContext *ic)
"Estimating duration from bitrate, this may be inaccurate\n");
}
-#define
Re: [FFmpeg-devel] [PATCH 4/6] avcodec/tiff: Improve inclusions
On date Sunday 2024-03-10 17:06:18 +0100, Andreas Rheinhardt wrote: > Stefano Sabatini: > >> diff --git a/libavcodec/tiff.h b/libavcodec/tiff.h > >> index e67c59abad..2dd21dea52 100644 > >> --- a/libavcodec/tiff.h > >> +++ b/libavcodec/tiff.h > >> @@ -30,9 +30,6 @@ > >> #ifndef AVCODEC_TIFF_H > >> #define AVCODEC_TIFF_H > >> > >> -#include > > > >> -#include "tiff_common.h" > > > > why? there are cases where only tiff.h must be used? > > > > Must? Like in most header matters, this is not a question of "must". > tiff.h provides (mostly) TIFF related defines that are independent of > any particular implementation, whereas tiff_common.h mostly provides > auxiliary functions for decoder/parser (the encoder only uses > type_sizes*). And not even all of these need it: faxcompr only needs > tiff.h, not tiff_common.h and mjpegdec.c needs only tiff_common.h. Makes sense, patch 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Mon, 11 Mar 2024, Anton Khirnov wrote: Well it IS obsolete. AFAIK it was never a particularly popular codec, and was only really used by the anime and ripping scenes in early 2000s, and even they dropped it very quickly once x264 appeared. Within the scene of mobile HW, they commonly had HW codecs for H263 and MPEG4 (or SW codecs), with many but not all also supporting H264. So for one specific generation of mobile devices, MPEG4 was the same level of lingua franca that H264 is today. Obviously not a big use case today in nontrivial numbers of course, but it is an example of a "scene" where the codec did have a pretty broad adoption. And again - that does not mean the capability should be removed, but it does mean that we shouldn't insist on tuning it for the smoothest user experience, since this time is then NOT spent doing something actually useful. I guess that's true. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Martin Storsjö via ffmpeg-devel (2024-03-11 15:03:15) > On Mon, 11 Mar 2024, Anton Khirnov wrote: > > >> I think the point is, that one can't just dismiss that anybody would want > >> to encode mpeg4 video any longer, even if it is obsolete. I also would > >> like to keep being able to do that. > > > > That capability is not going away though, and I'm not arguing that it > > should. > > Ok, good. The generally dismissive arguments about mpeg4 encoding being > obsolete and something that nobody should be doing, could be interpreted > in such a way. Well it IS obsolete. AFAIK it was never a particularly popular codec, and was only really used by the anime and ripping scenes in early 2000s, and even they dropped it very quickly once x264 appeared. While hardware "divx players" did exist, I don't think they'd still be used today in nontrivial numbers. So I don't see any reason to encode it today, besides testing and academic/historic interest. And again - that does not mean the capability should be removed, but it does mean that we shouldn't insist on tuning it for the smoothest user experience, since this time is then NOT spent doing something actually useful. > > Specifically, the commandline used by Michael involves the extremely > > obscure case of converting subtitles to video (NOT harsubbing, but > > really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to > > AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4 > > encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1 > > video), the input video timebase should be used, which would probably > > work. > > > > I don't think it's that big of a deal to require users to specify the > > timebase or framerate explicitly in such a sitation. > > Inventing new APIs to cover it automagically seems like a waste of time, > > unless somebody has actual (not potential) uses for this. > > Right, I would agree with this. (If someone else would volunteer to add > said API I would consider accepting it though.) > > Is this a usecase that currently works, but would be go away by getting > rid of codec specific code in the tools, or is it a nice-to-have new extra > feature that is being requested? The patch is not removing codec-specific code, rather it is changing the filtering timebase from the demuxer one to the decoder one (which is needed in this set to avoid the assumption that a filter is necessarily fed by a demuxer). The two should be the same in most cases, except * sub2video, where the subtitle decoding API fixes the timebase to AV_TIME_BASE_Q * there is a post-demuxing bsf that changes the timebase, such as setts -- 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On 11/03/2024 14:28, Anton Khirnov wrote: Quoting Martin Storsjö (2024-03-11 13:29:15) On Mon, 11 Mar 2024, Anton Khirnov wrote: Quoting Tobias Rapp (2024-03-11 11:12:38) On 10/03/2024 23:49, Anton Khirnov wrote: Quoting James Almer (2024-03-10 23:29:27) On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 04:36:29) why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. Hardware doesn't get outdated as quickly as software. And there are people that do not switch their full environment to a new codec every decade just to be "in line". And your point is...? I think the point is, that one can't just dismiss that anybody would want to encode mpeg4 video any longer, even if it is obsolete. I also would like to keep being able to do that. That capability is not going away though, and I'm not arguing that it should. That said, I haven't followed the discussion closely enough about what to do with the time bases. The only change is that in some rare cases the automatically selected timebase no longer fits into mpeg4 constraints, so the user has to specify either the framerate or the timebase explicitly. [...] If this is just about having to add some extra parametersin rare use-cases then its fine. I got the impression that encoding into MPEG4 or DV was considered deprecated (or unimportant of additional consideration) in general. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the outpu
Andreas Rheinhardt:
> 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
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Mon, 11 Mar 2024, Anton Khirnov wrote: I think the point is, that one can't just dismiss that anybody would want to encode mpeg4 video any longer, even if it is obsolete. I also would like to keep being able to do that. That capability is not going away though, and I'm not arguing that it should. Ok, good. The generally dismissive arguments about mpeg4 encoding being obsolete and something that nobody should be doing, could be interpreted in such a way. That said, I haven't followed the discussion closely enough about what to do with the time bases. The only change is that in some rare cases the automatically selected timebase no longer fits into mpeg4 constraints, so the user has to specify either the framerate or the timebase explicitly. Right, I see. Specifically, the commandline used by Michael involves the extremely obscure case of converting subtitles to video (NOT harsubbing, but really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4 encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1 video), the input video timebase should be used, which would probably work. I don't think it's that big of a deal to require users to specify the timebase or framerate explicitly in such a sitation. Inventing new APIs to cover it automagically seems like a waste of time, unless somebody has actual (not potential) uses for this. Right, I would agree with this. (If someone else would volunteer to add said API I would consider accepting it though.) Is this a usecase that currently works, but would be go away by getting rid of codec specific code in the tools, or is it a nice-to-have new extra feature that is being requested? // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/1] avcodec/dolby_e: Add error recovery when parse_mantissas run out of bits
Mantissas are the last data in the channel subsegment and it appears it
is sometimes missing a very few bits for the parsing to complete.
This must not be confused with data corruption.
In standard conditions with certified products, it has been observed
that the occurence of this issue is pretty steady and about once every 2
hours. The truncation is at about 950 out of the 1024 values (923 is the
minimum I have seen so far).
The current code raises a severe 'Read past end' error and all data is
lost resulting in 20ms(@25fps) of silence for the affected channel.
This patch introduces a tolerance: if 800 out of the 1024 mantissas have
been parsed, a simple warning is raised and the data is preserved.
Signed-off-by: Nicolas Gaullier
---
libavcodec/dolby_e.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/dolby_e.c b/libavcodec/dolby_e.c
index 9c3f6006c2..1f8442e2e9 100644
--- a/libavcodec/dolby_e.c
+++ b/libavcodec/dolby_e.c
@@ -845,6 +845,7 @@ static int parse_indices(DBEContext *s, DBEChannel *c)
return 0;
}
+#define MIN_MANTISSAS 800
static int parse_mantissas(DBEContext *s, DBEChannel *c)
{
DBEGroup *g;
@@ -885,6 +886,13 @@ static int parse_mantissas(DBEContext *s, DBEChannel *c)
}
}
} else {
+if (i == c->nb_groups - 1
+&& count * size1 > get_bits_left(>gb)
+&& get_bits_left(>gb) >= 0
+&& (int)(mnt - c->mantissas) >= MIN_MANTISSAS) {
+av_log(s->avctx, AV_LOG_WARNING, "Truncated mantissas @%d,
highest frequencies not recoverable\n", (int)(mnt - c->mantissas));
+break;
+}
for (k = 0; k < count; k++)
mnt[k] = get_sbits(>gb, size1) * scale;
}
--
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 0/1] avcodec/dolby_e: Add error recovery when parse_mantissas run out of bits
A new ping for this same old topic. Previously with no feedback at all: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7482 I just "rebased"-retested it. Updates: wrapped lines of commit msg The samples (source/before patch/after patch) are still available on https://0x0.st/oOvv.zip Nicolas Gaullier (1): avcodec/dolby_e: Add error recovery when parse_mantissas run out of bits libavcodec/dolby_e.c | 8 1 file changed, 8 insertions(+) -- 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] When the silencedetect filter is run against long files, the output timestamps gradually lose precision as the scan proceeds further into the file. This is because the outpu
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
Re: [FFmpeg-devel] [PATCH] doc/examples/qsv_decode.c: remove unused config.h header file
> 在 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 ___ 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Martin Storsjö (2024-03-11 13:29:15) > On Mon, 11 Mar 2024, Anton Khirnov wrote: > > > Quoting Tobias Rapp (2024-03-11 11:12:38) > >> On 10/03/2024 23:49, Anton Khirnov wrote: > >> > >>> Quoting James Almer (2024-03-10 23:29:27) > On 3/10/2024 7:24 PM, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-03-10 20:21:47) > >> On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > >>> Quoting Michael Niedermayer (2024-03-10 04:36:29) > why not automatically choose a supported timebase ? > "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 > standard, the maximum admitted value for the timebase denominator is > 65535" > >>> Because I don't want ffmpeg CLI to have codec-specific code for a > >>> codec > >>> that's been obsolete for 15+ years. One could also potentially do it > >>> inside the encoder itself, but it is nontrivial since the computations > >>> are spread across a number of places in mpeg4videoenc.c and > >>> mpegvideo_enc.c. And again, it seems like a waste of time - there is > >>> no > >>> reason to encode mpeg4 today. > >> This is not mpeg4 specific, its just a new additional case that fails > > The case you reported is mpeg4 specific. > > > >> ./ffmpeg -i mm-small.mpg test.dv > >> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p > >> video. Valid DV profiles are: > > There is no mechanism for an encoder to export supported time bases. > Could it be added as an extension to AVProfile, or AVCodec? > >>> The two cases are actually pretty different: > >>> * mpeg4 has a constraint on the range of timebases, and actually does > >>>some perverted computations with the timestamps > >>> * DV just needs your video to be CFR, with a list of supported > >>>framerates; dvenc should probably read AVCodecContext.framerate > >>>instead of time_base > >>> > >>> But most importantly, is there an actual current use case for either of > >>> those encoders? They have both been obsolete for close to two decades. > >>> It seems silly to add new API that won't actually be useful to anyone. > >> > >> Hardware doesn't get outdated as quickly as software. And there are > >> people that do not switch their full environment to a new codec every > >> decade just to be "in line". > > > > And your point is...? > > I think the point is, that one can't just dismiss that anybody would want > to encode mpeg4 video any longer, even if it is obsolete. I also would > like to keep being able to do that. That capability is not going away though, and I'm not arguing that it should. > That said, I haven't followed the discussion closely enough about what to > do with the time bases. The only change is that in some rare cases the automatically selected timebase no longer fits into mpeg4 constraints, so the user has to specify either the framerate or the timebase explicitly. Specifically, the commandline used by Michael involves the extremely obscure case of converting subtitles to video (NOT harsubbing, but really 1 sub -> 1 video). Since subtitle encoding API is hardcoded to AV_TIME_BASE_Q, that timebase gets used for encoding, and the mpeg4 encoder rejects it. If it was hardsubbing (i.e. 1 video + 1 sub -> 1 video), the input video timebase should be used, which would probably work. I don't think it's that big of a deal to require users to specify the timebase or framerate explicitly in such a sitation. Inventing new APIs to cover it automagically seems like a waste of time, unless somebody has actual (not potential) uses for this. -- 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On Mon, 11 Mar 2024, Anton Khirnov wrote: Quoting Tobias Rapp (2024-03-11 11:12:38) On 10/03/2024 23:49, Anton Khirnov wrote: Quoting James Almer (2024-03-10 23:29:27) On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 04:36:29) why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. Hardware doesn't get outdated as quickly as software. And there are people that do not switch their full environment to a new codec every decade just to be "in line". And your point is...? I think the point is, that one can't just dismiss that anybody would want to encode mpeg4 video any longer, even if it is obsolete. I also would like to keep being able to do that. That said, I haven't followed the discussion closely enough about what to do with the time bases. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Tobias Rapp (2024-03-11 11:12:38) > On 10/03/2024 23:49, Anton Khirnov wrote: > > > Quoting James Almer (2024-03-10 23:29:27) > >> On 3/10/2024 7:24 PM, Anton Khirnov wrote: > >>> Quoting Michael Niedermayer (2024-03-10 20:21:47) > On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2024-03-10 04:36:29) > >> why not automatically choose a supported timebase ? > >> "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 > >> standard, the maximum admitted value for the timebase denominator is > >> 65535" > > Because I don't want ffmpeg CLI to have codec-specific code for a codec > > that's been obsolete for 15+ years. One could also potentially do it > > inside the encoder itself, but it is nontrivial since the computations > > are spread across a number of places in mpeg4videoenc.c and > > mpegvideo_enc.c. And again, it seems like a waste of time - there is no > > reason to encode mpeg4 today. > This is not mpeg4 specific, its just a new additional case that fails > >>> The case you reported is mpeg4 specific. > >>> > ./ffmpeg -i mm-small.mpg test.dv > [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. > Valid DV profiles are: > >>> There is no mechanism for an encoder to export supported time bases. > >> Could it be added as an extension to AVProfile, or AVCodec? > > The two cases are actually pretty different: > > * mpeg4 has a constraint on the range of timebases, and actually does > >some perverted computations with the timestamps > > * DV just needs your video to be CFR, with a list of supported > >framerates; dvenc should probably read AVCodecContext.framerate > >instead of time_base > > > > But most importantly, is there an actual current use case for either of > > those encoders? They have both been obsolete for close to two decades. > > It seems silly to add new API that won't actually be useful to anyone. > > Hardware doesn't get outdated as quickly as software. And there are > people that do not switch their full environment to a new codec every > decade just to be "in line". And your point is...? -- 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".
[FFmpeg-devel] [PATCH v3] avcodec/libx264: fix extradata when config annexb=0
From: Zhao Zhili
---
v3: Remove unnecessary inclusion
configure| 2 +-
libavcodec/libx264.c | 132 +++
2 files changed, 109 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..b90e3f4fe1 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,110 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
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++) {
+if (nal[i].i_type == NAL_SPS)
+sps_nal = [i];
+else if (nal[i].i_type == NAL_PPS)
+pps_nal = [i];
+}
+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(, sps, sps_nal->i_payload - 4);
+skip_bits(, 8);
+ret = ff_h264_decode_seq_parameter_set(, avctx, , 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();
+}
+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, , );
+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) {
+av_log(avctx, AV_LOG_INFO, "%s\n", nal[i].p_payload + 25);
+x4->sei_size = nal[i].i_payload;
+x4->sei = av_malloc(x4->sei_size);
+if (!x4->sei)
+return AVERROR(ENOMEM);
+memcpy(x4->sei, nal[i].p_payload, nal[i].i_payload);
+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_parse(>params, name, x4->var) < 0) {\
av_log(avctx, AV_LOG_ERROR, "Error parsing option '%s' with value
'%s'.\n", name, x4->var);\
@@ -1233,30 +1338,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
return AVERROR_EXTERNAL;
if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER) {
-x264_nal_t *nal;
-uint8_t *p;
-int nnal, s, i;
-
-s = x264_encoder_headers(x4->enc, , );
-avctx->extradata =
[FFmpeg-devel] [PATCH] doc/fate: advise on --assert-level=2
Signed-off-by: Nicolas Gaullier
---
doc/fate.texi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/doc/fate.texi b/doc/fate.texi
index 2fa8c34c2d..2fa7c70251 100644
--- a/doc/fate.texi
+++ b/doc/fate.texi
@@ -79,6 +79,13 @@ 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
+
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".
[FFmpeg-devel] [PATCH 0/1] doc/fate: advise on --assert-level=2
In my personnal experience, when running fate, --assert-level=2 has a very limited performance impact, so I think it can be recommended without further attention. Nicolas Gaullier (1): doc/fate: advise on --assert-level=2 doc/fate.texi | 7 +++ 1 file changed, 7 insertions(+) -- 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
On 10/03/2024 23:49, Anton Khirnov wrote: Quoting James Almer (2024-03-10 23:29:27) On 3/10/2024 7:24 PM, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 20:21:47) On Sun, Mar 10, 2024 at 07:13:18AM +0100, Anton Khirnov wrote: Quoting Michael Niedermayer (2024-03-10 04:36:29) why not automatically choose a supported timebase ? "[mpeg4 @ 0x55973c869f00] timebase 1/100 not supported by MPEG 4 standard, the maximum admitted value for the timebase denominator is 65535" Because I don't want ffmpeg CLI to have codec-specific code for a codec that's been obsolete for 15+ years. One could also potentially do it inside the encoder itself, but it is nontrivial since the computations are spread across a number of places in mpeg4videoenc.c and mpegvideo_enc.c. And again, it seems like a waste of time - there is no reason to encode mpeg4 today. This is not mpeg4 specific, its just a new additional case that fails The case you reported is mpeg4 specific. ./ffmpeg -i mm-small.mpg test.dv [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p video. Valid DV profiles are: There is no mechanism for an encoder to export supported time bases. Could it be added as an extension to AVProfile, or AVCodec? The two cases are actually pretty different: * mpeg4 has a constraint on the range of timebases, and actually does some perverted computations with the timestamps * DV just needs your video to be CFR, with a list of supported framerates; dvenc should probably read AVCodecContext.framerate instead of time_base But most importantly, is there an actual current use case for either of those encoders? They have both been obsolete for close to two decades. It seems silly to add new API that won't actually be useful to anyone. Hardware doesn't get outdated as quickly as software. And there are people that do not switch their full environment to a new codec every decade just to be "in line". Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: update filter timeline state only on main link
On 2024-03-06 11:02 am, Gyan Doshi wrote: On 2024-03-01 07:41 pm, Gyan Doshi wrote: At present, consume_update evaluates timeline state on all links for a multi-input filter. This can lead to the filter being incorrectly en/dis-abled when evaluation on a frame on a secondary link leads to a different result than the frame on the current main link next in line for processing. Ping. Plan to apply in 72h, barring objections. Pushed as 3d1860ec8db7f9785bf1338e826138c0218dfb59 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 02/18] fftools/ffmpeg_filter: refactor setting input timebase
Quoting Michael Niedermayer (2024-03-11 00:37:07) > > > >>> Because I don't want ffmpeg CLI to have codec-specific code for a > > > >>> codec > > > >>> that's been obsolete for 15+ years. One could also potentially do it > > > >>> inside the encoder itself, but it is nontrivial since the computations > > > >>> are spread across a number of places in mpeg4videoenc.c and > > > >>> mpegvideo_enc.c. And again, it seems like a waste of time - there is > > > >>> no > > > >>> reason to encode mpeg4 today. > > > >> > > > >> This is not mpeg4 specific, its just a new additional case that fails > > > > > > > > The case you reported is mpeg4 specific. > > > > > > > >> ./ffmpeg -i mm-small.mpg test.dv > > > >> [dvvideo @ 0x7f868800f100] Found no DV profile for 80x60 yuv420p > > > >> video. Valid DV profiles are: > > > > > > > > There is no mechanism for an encoder to export supported time bases. > > > > > > Could it be added as an extension to AVProfile, or AVCodec? > > > > The two cases are actually pretty different: > > * mpeg4 has a constraint on the range of timebases, and actually does > > some perverted computations with the timestamps > > * DV just needs your video to be CFR, with a list of supported > > framerates; dvenc should probably read AVCodecContext.framerate > > instead of time_base > > > > But most importantly, is there an actual current use case for either of > > those encoders? They have both been obsolete for close to two decades. > > It seems silly to add new API that won't actually be useful to anyone. > > iam not sugesting to add API specific to mpeg4, rather that maybe > it can be done as part of some more generic solution What kind of a solution? As I said above, I don't know of any other encoders that have similar constraints. -- 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".
