Re: [FFmpeg-devel] [PATCH v2] doc: add spi.txt
On date Monday 2023-10-16 00:49:56 +0200, Michael Niedermayer wrote: > This explains how to request refunds and what can be funded by SPI > > Co-Author: Stefano Sabatini > --- > doc/spi.txt | 73 + > 1 file changed, 73 insertions(+) > create mode 100644 doc/spi.txt > > diff --git a/doc/spi.txt b/doc/spi.txt > new file mode 100644 > index 00..ff4af8f42b > --- /dev/null > +++ b/doc/spi.txt > @@ -0,0 +1,73 @@ > +SPI (Software in the Public Interest) is a non-profit corporation > +registered in the state of New York founded to act as a fiscal sponsor > +for organizations that develop open source software and hardware. For > +details check here: > +https://www.spi-inc.org/ > + > +FFmpeg is an SPI associated project and donations can be collected and > +handled by SPI on behalf of FFmpeg. For details about the association > +check here: > +https://www.spi-inc.org/projects/ffmpeg/ > + > + > +How to request refunds from SPI: > + > +Send a mail to ffmpeg-devel with the [REFUND-REQUEST] tag and a short > +description of the refund topic in the subject. > + > +In the mail, you also need to provide the amount to be refunded, with > +a short description of how the money was spent. > + > +There is no need and is not recommeded to send receipts when sending > +the refund request on the ffmpeg-devel mailing-list, but they are > +usually needed later when the request is approved and the refund > +request is sent to SPI: > +https://www.spi-inc.org/treasurer/reimbursement-form/ > + > + > +What can be payed by SPI: > +- > +FFmpeg money collected at SPI can be used for any purpose which is in line > with > +501(c)3 nonprofit rules, and within our mission (Free & OSS software). > + > +In practice we frequently payed for travel and hardware. > +For other refund expenses or sponsorships, it is recommended to > +discuss them beforehand on ffmpeg-devel. If there is a community > +agreement on their approval, the current FFmpeg liaison will followup > +to get an approval on the SPI side. > + > + > +Is it possible to fund active development by SPI: > +(the texts below have been taken from multiple > + replies FFmpeg has received from SPI, they have been edited > + so that "I" was replaced by "SPI" in some cases.) > +- This is a mix of a question and a title. My take: Funding active development by SPI: -- The text below have been taken from multiple replies FFmpeg has received from SPI. [...] > +Paying for development *does* require substantial > +additional paperwork, but it is not prohibited. > + > +Several SPI projects pay contractors for development > +efforts. SPI needs a contract in place which describes the work to be > +done. There are also various things SPI needs to check (e.g. are they a needs to check about the potential contractors (... > +US person or not, as with GSoC mentor payments; are they really a > +contractor and not a employee). > + > +SPI can't deal with employment at the moment because that involves a > +lot of work, like health insurance, tax withholding, etc. Contractors > +are easier because they have to take care of that themselves; Whether > +someone is a contractor vs employee depends on various factors (that > +of course are different in every country) and can be disputed (see > +e.g. the debate about whether Uber drivers are employees); SPI has a > +questionnaire about their circumstances.) > + > +Unfortunately, there's no one-size-fits all when dealing with contractors. > +As already mentioned, without knowing the contributor's country Unfortunately, there's no one-size-fits all when dealing with contractors, especially without knowing the contributor's country. > + > +SPI does have templates, but they depend on the contractors country. If it's > +US, Australia, France and a couple others SPI could provide them next day, > +otherwise SPI would need to ask their attorney to draft one, which would > +take some time SPI does have some contract templates which depends on the contractors country. In case of US, Australia, France and a couple others countries, SPI can easily provide them, otherwise SPI would need to ask their attorney to draft one, which would take some time > + > +Also, SPI has two models, MSA (which transfers ownership) and CSA (which > +grants a license instead). SPI usually sends the MSA (it's better for most > +purposes), but for development purposes, some projects prefer that the > +contractor retains ownership rights. [...] LGTM otherwise and can be tweaked once in. ___ ffmpeg-devel mailing list ffmpeg-devel@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] doc: add spi.txt
On date Monday 2023-10-16 06:34:45 +0200, Lynne wrote: > Oct 16, 2023, 00:50 by mich...@niedermayer.cc: > > > This explains how to request refunds and what can be funded by SPI > > > > Co-Author: Stefano Sabatini > > --- > > doc/spi.txt | 73 + > > 1 file changed, 73 insertions(+) > > create mode 100644 doc/spi.txt > > > > diff --git a/doc/spi.txt b/doc/spi.txt > > new file mode 100644 > > index 00..ff4af8f42b > > > > Again, I think this belongs on the website, not in our codebase. Given that this is a sort of internal memo, and that is targeted at developers rather than final users, I see no value into exposing this in the website (and we have similar documents - e.g. community.texi - already in doc). OTOH given that this clarifies how donations are spent, there is also a value into making this more transparent to users/donors, but I don't see this as blocking (we can publish it here and then move it to the website once the process has been consolidated). ___ ffmpeg-devel mailing list ffmpeg-devel@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/3] lavc/libaribcaption.c: add MSZ characters related options
This patch add MSZ (Middle Size; half width) characters related options and some fixes. As Jan suggested to PATCH v2, I split it into 3 patches, drop `#if`s, and bump required libaribcaption version to 1.1.1 (author preferred version). TADANO Tokumei (3): lavc/libaribcaption.c: FIX: change all `boot` option var to `int` lavc/libaribcaption.c: add MSZ characters related options lavc/libaribcaption.c: rename `-replace_fullwidth_ascii` option configure | 2 +- doc/decoders.texi | 28 ++-- libavcodec/libaribcaption.c | 28 +++- 3 files changed, 42 insertions(+), 16 deletions(-) -- 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] [PATCH v3 1/3] lavc/libaribcaption.c: FIX: change all `boot` option var to `int`
This patch fixes a bug in curret version.
On some environments, a `bool` variable is small space than `int`.
If a `bool` option was specified by command line, following
variables would be filled and may be destroyed by av_opt_copy().
This patch change all the `bool` option variables in
`ARIBCaptionContext` to `int`.
Signed-off-by: TADANO Tokumei
---
libavcodec/libaribcaption.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..be3328c5c9 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -68,14 +68,14 @@ typedef struct ARIBCaptionContext {
int subtitle_type;
int encoding_scheme;
-bool ass_single_rect;
+int ass_single_rect;
char *font;
-bool replace_fullwidth_ascii;
-bool force_stroke_text;
-bool ignore_background;
-bool ignore_ruby;
+int replace_fullwidth_ascii;
+int force_stroke_text;
+int ignore_background;
+int ignore_ruby;
float stroke_width;
-bool replace_drcs;
+int replace_drcs;
int64_t pts;
AVRational time_base;
--
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] [PATCH v3 2/3] lavc/libaribcaption.c: add MSZ characters related options
This patch add MSZ (Middle Size; half width) characters related
options.
* add `-replace_msz_japanese` option introduced in version 1.0.1
of libaribcaption.
* add `-replace_msz_glyph` option introduced in version 1.1.0
of libaribcaption.
If specified fonts contain half-width glyphs (e.g., BIZ UDGothic),
it make better rendering with `-replace_msz_ascii false` and
`-replace_msz_japanese false` option for bitmap sub_type.
Signed-off-by: TADANO Tokumei
---
configure | 2 +-
doc/decoders.texi | 16
libavcodec/libaribcaption.c | 10 ++
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index d203177a74..2fb827e1fb 100755
--- a/configure
+++ b/configure
@@ -6679,7 +6679,7 @@ enabled libaom&& require_pkg_config libaom
"aom >= 1.0.0" aom/aom_co
enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
"aribb24/aribb24.h" arib_instance_new ||
{ enabled gpl && require_pkg_config libaribb24
aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
die "ERROR: libaribb24 requires version higher
than 1.0.3 or --enable-gpl."; }
-enabled libaribcaption&& require_pkg_config libaribcaption "libaribcaption
>= 0.1.0" "aribcaption/aribcaption.h" aribcc_context_alloc
+enabled libaribcaption&& require_pkg_config libaribcaption "libaribcaption
>= 1.1.1" "aribcaption/aribcaption.h" aribcc_context_alloc
enabled lv2 && require_pkg_config lv2 lilv-0 "lilv/lilv.h"
lilv_world_new
enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
enabled libass&& require_pkg_config libass "libass >= 0.11.0"
ass/ass.h ass_library_init
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..36c3404475 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -459,6 +459,22 @@ Specify whether to render replaced DRCS characters as
Unicode characters.
The default is @var{true}.
+@item -replace_msz_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size; half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
+@item -replace_msz_glyph @var{boolean}
+Specify whether to replace MSZ (Middle Size; half width) characters
+with halfwidth glyphs if the fonts supports it.
+This option works under FreeType or DirectWrite renderer
+with Adobe-Japan1 compliant fonts.
+e.g., IBM Plex Sans JP, Morisawa BIZ UDGothic, Morisawa BIZ UDMincho,
+Yu Gothic, Yu Mincho, and Meiryo.
+
+The default is @var{true}.
+
@item -canvas_size @var{image_size}
Specify the resolution of the canvas to render subtitles to; usually, this
should be frame size of input video.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index be3328c5c9..74822586dc 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -76,6 +76,8 @@ typedef struct ARIBCaptionContext {
int ignore_ruby;
float stroke_width;
int replace_drcs;
+int replace_msz_japanese;
+int replace_msz_glyph;
int64_t pts;
AVRational time_base;
@@ -1005,6 +1007,8 @@ static int aribcaption_init(AVCodecContext *avctx)
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
ctx->replace_fullwidth_ascii);
+aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+ ctx->replace_msz_japanese);
/* Similar behavior as ffmpeg tool to set canvas size */
if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1057,6 +1061,8 @@ static int aribcaption_init(AVCodecContext *avctx)
aribcc_renderer_set_force_no_background(ctx->renderer,
ctx->ignore_background);
aribcc_renderer_set_force_no_ruby(ctx->renderer, ctx->ignore_ruby);
aribcc_renderer_set_stroke_width(ctx->renderer, ctx->stroke_width);
+aribcc_renderer_set_replace_msz_halfwidth_glyph(ctx->renderer,
+
ctx->replace_msz_glyph);
if (ctx->font) {
int is_nomem = 0;
size_t count = 0;
@@ -1144,6 +1150,10 @@ static const AVOption options[] = {
OFFSET(stroke_width), AV_OPT_TYPE_FLOAT, { .dbl = 1.5 }, 0.0, 3.0, SD },
{ "replace_drcs", "replace known DRCS [bitmap]",
OFFSET(replace_drcs), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_japanese", "replace MSZ fullwidth Japanese with halfwidth
[ass, bitmap]",
+ OFFSET(replace_msz_japanese), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_glyph", "replace MSZ characters with halfwidth glyphs
[bitmap]",
+ OFFSET(replace_msz_glyph), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{"canvas_size", "set input video size (WxH or abbreviation) [bitmap]",
OFFSET(can
[FFmpeg-devel] [PATCH v3 3/3] lavc/libaribcaption.c: rename `-replace_fullwidth_ascii` option
This patch renames `-replace_fullwidth_ascii` option to
`-replace_msz_ascii` to clarify option meaning.
Signed-off-by: TADANO Tokumei
---
doc/decoders.texi | 12 ++--
libavcodec/libaribcaption.c | 8
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 36c3404475..eb00e2a9e9 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -427,12 +427,6 @@ If your player cannot handle AVSubtitles with multiple ASS
rectangles properly,
set this option to @var{true} or define @env{ASS_SINGLE_RECT=1} to change
default behavior at compilation.
-@item -replace_fullwidth_ascii @var{boolean}
-Specify whether to replace MSZ (Middle Size, half width) fullwidth
-alphanumerics with halfwidth alphanumerics.
-
-The default is @var{true}.
-
@item -force_outline_text @var{boolean}
Specify whether always render outline text for all characters regardless of
the indication by charactor style.
@@ -459,6 +453,12 @@ Specify whether to render replaced DRCS characters as
Unicode characters.
The default is @var{true}.
+@item -replace_msz_ascii @var{boolean}
+Specify whether to replace MSZ (Middle Size; half width) fullwidth
+alphanumerics with halfwidth alphanumerics.
+
+The default is @var{true}.
+
@item -replace_msz_japanese @var{boolean}
Specify whether to replace some MSZ (Middle Size; half width) fullwidth
japanese special characters with halfwidth ones.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 74822586dc..2a058a4992 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -70,12 +70,12 @@ typedef struct ARIBCaptionContext {
int encoding_scheme;
int ass_single_rect;
char *font;
-int replace_fullwidth_ascii;
int force_stroke_text;
int ignore_background;
int ignore_ruby;
float stroke_width;
int replace_drcs;
+int replace_msz_ascii;
int replace_msz_japanese;
int replace_msz_glyph;
@@ -1006,7 +1006,7 @@ static int aribcaption_init(AVCodecContext *avctx)
return AVERROR_EXTERNAL;
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
-
ctx->replace_fullwidth_ascii);
+ ctx->replace_msz_ascii);
aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
ctx->replace_msz_japanese);
@@ -1138,8 +1138,6 @@ static const AVOption options[] = {
OFFSET(ass_single_rect), AV_OPT_TYPE_BOOL, { .i64 = ASS_SINGLE_RECT },
0, 1, SD },
{ "font", "comma-separated font family [ass, bitmap]",
OFFSET(font), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD },
-{ "replace_fullwidth_ascii", "replace MSZ fullwidth alphanumerics with
halfwidth alphanumerics [ass, bitmap]",
- OFFSET(replace_fullwidth_ascii), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1,
SD },
{ "force_outline_text", "always render characters with outline [(ass),
bitmap]",
OFFSET(force_stroke_text), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, SD },
{ "ignore_background", "ignore rendering caption background [(ass),
bitmap]",
@@ -1150,6 +1148,8 @@ static const AVOption options[] = {
OFFSET(stroke_width), AV_OPT_TYPE_FLOAT, { .dbl = 1.5 }, 0.0, 3.0, SD },
{ "replace_drcs", "replace known DRCS [bitmap]",
OFFSET(replace_drcs), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_ascii", "replace MSZ fullwidth alphanumerics with halfwidth
alphanumerics [ass, bitmap]",
+ OFFSET(replace_msz_ascii), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{ "replace_msz_japanese", "replace MSZ fullwidth Japanese with halfwidth
[ass, bitmap]",
OFFSET(replace_msz_japanese), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{ "replace_msz_glyph", "replace MSZ characters with halfwidth glyphs
[bitmap]",
--
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] [PATCH 2/5] aarch64: Lowercase UXTW/SXTW and similar flags
---
libavcodec/aarch64/h264cmc_neon.S | 4 +-
libavcodec/aarch64/h264idct_neon.S| 2 +-
libavfilter/aarch64/vf_bwdif_neon.S | 6 +-
libavfilter/aarch64/vf_nlmeans_neon.S | 8 +-
libswscale/aarch64/hscale.S | 176 +-
libswscale/aarch64/yuv2rgb_neon.S | 14 +-
6 files changed, 105 insertions(+), 105 deletions(-)
diff --git a/libavcodec/aarch64/h264cmc_neon.S
b/libavcodec/aarch64/h264cmc_neon.S
index 5b959b87d3..2ddd5c8a53 100644
--- a/libavcodec/aarch64/h264cmc_neon.S
+++ b/libavcodec/aarch64/h264cmc_neon.S
@@ -38,7 +38,7 @@ function ff_\type\()_\codec\()_chroma_mc8_neon, export=1
lsl w9, w9, #3
lsl w10, w10, #1
add w9, w9, w10
-add x6, x6, w9, UXTW
+add x6, x6, w9, uxtw
ld1r{v22.8h}, [x6]
.endif
.ifc \codec,vc1
@@ -208,7 +208,7 @@ function ff_\type\()_\codec\()_chroma_mc4_neon, export=1
lsl w9, w9, #3
lsl w10, w10, #1
add w9, w9, w10
-add x6, x6, w9, UXTW
+add x6, x6, w9, uxtw
ld1r{v22.8h}, [x6]
.endif
.ifc \codec,vc1
diff --git a/libavcodec/aarch64/h264idct_neon.S
b/libavcodec/aarch64/h264idct_neon.S
index 1bab2ca7c8..3f7ff2c49e 100644
--- a/libavcodec/aarch64/h264idct_neon.S
+++ b/libavcodec/aarch64/h264idct_neon.S
@@ -385,7 +385,7 @@ function ff_h264_idct8_add4_neon, export=1
movrel x14, .L_ff_h264_idct8_add_neon
1: ldrbw9, [x7], #4
ldrsw x0, [x5], #16
-ldrbw9, [x4, w9, UXTW]
+ldrbw9, [x4, w9, uxtw]
subsw9, w9, #1
b.lt2f
ldrsh w11, [x1]
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index ae9aab20cd..bf268b12f8 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -186,13 +186,13 @@ function ff_bwdif_filter_line3_neon, export=1
mov w10, w6 // w10 = loop count
neg w9, w5 // w9 = mref
lsl w8, w9, #1// w8 = mref2
-add w7, w9, w9, LSL #1// w7 = mref3
+add w7, w9, w9, lsl #1// w7 = mref3
lsl w6, w9, #2// w6 = mref4
mov w11, w5 // w11 = pref
lsl w12, w5, #1// w12 = pref2
-add w13, w5, w5, LSL #1// w13 = pref3
+add w13, w5, w5, lsl #1// w13 = pref3
lsl w14, w5, #2// w14 = pref4
-add w15, w5, w5, LSL #2// w15 = pref5
+add w15, w5, w5, lsl #2// w15 = pref5
add w16, w14, w12 // w16 = pref6
lsl w5, w1, #1// w5 = d_stride * 2
diff --git a/libavfilter/aarch64/vf_nlmeans_neon.S
b/libavfilter/aarch64/vf_nlmeans_neon.S
index 26d6958b82..a788cffd85 100644
--- a/libavfilter/aarch64/vf_nlmeans_neon.S
+++ b/libavfilter/aarch64/vf_nlmeans_neon.S
@@ -35,10 +35,10 @@
function ff_compute_safe_ssd_integral_image_neon, export=1
moviv26.4s, #0 //
used as zero for the "rotations" in acc_sum_store
-sub x3, x3, w6, UXTW// s1
padding (s1_linesize - w)
-sub x5, x5, w6, UXTW// s2
padding (s2_linesize - w)
-sub x9, x0, w1, UXTW #2 //
dst_top
-sub x1, x1, w6, UXTW// dst
padding (dst_linesize_32 - w)
+sub x3, x3, w6, uxtw// s1
padding (s1_linesize - w)
+sub x5, x5, w6, uxtw// s2
padding (s2_linesize - w)
+sub x9, x0, w1, uxtw #2 //
dst_top
+sub x1, x1, w6, uxtw// dst
padding (dst_linesize_32 - w)
lsl x1, x1, #2 // dst
padding expressed in bytes
1: mov w10, w6 //
width copy for each line
sub x0, x0, #16 //
beginning of the dst line minus 4 sums
diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
index f3c404eb5f..3041d483fc 100644
--- a/libswscale/aarch64/hscale.S
+++ b/libswscale/aarch64/hscale.S
@@ -54,10 +54,10 @@ function
[FFmpeg-devel] [PATCH 3/5] aarch64: Make the indentation more consistent
Some functions have slightly different indentation styles; try
to match the surrounding code.
libavcodec/aarch64/vc1dsp_neon.S is skipped here, as it intentionally
uses a layered indentation style to visually show how different
unrolled/interleaved phases fit together.
---
libavcodec/aarch64/h264dsp_neon.S | 8 +-
libavcodec/aarch64/h264qpel_neon.S | 12 +-
libavcodec/aarch64/hevcdsp_idct_neon.S | 256 ++--
libavcodec/aarch64/hevcdsp_qpel_neon.S | 24 +-
libavcodec/aarch64/opusdsp_neon.S | 8 +-
libavcodec/aarch64/vp8dsp_neon.S | 310 -
libavutil/aarch64/tx_float_neon.S | 12 +-
7 files changed, 315 insertions(+), 315 deletions(-)
diff --git a/libavcodec/aarch64/h264dsp_neon.S
b/libavcodec/aarch64/h264dsp_neon.S
index 71c2ddfd0c..723b692019 100644
--- a/libavcodec/aarch64/h264dsp_neon.S
+++ b/libavcodec/aarch64/h264dsp_neon.S
@@ -526,7 +526,7 @@ function ff_h264_h_loop_filter_chroma_mbaff_intra_neon,
export=1
ld1 {v17.8b}, [x4], x1
ld1 {v19.8b}, [x4], x1
-transpose_4x8B v18, v16, v17, v19, v26, v27, v28, v29
+transpose_4x8B v18, v16, v17, v19, v26, v27, v28, v29
h264_loop_filter_chroma_intra
@@ -554,7 +554,7 @@ h_loop_filter_chroma420_intra:
ld1 {v17.s}[1], [x4], x1
ld1 {v19.s}[1], [x4], x1
-transpose_4x8B v18, v16, v17, v19, v26, v27, v28, v29
+transpose_4x8B v18, v16, v17, v19, v26, v27, v28, v29
h264_loop_filter_chroma_intra
@@ -1017,7 +1017,7 @@ function
ff_h264_h_loop_filter_chroma_mbaff_intra_neon_10, export=1
ld1 {v16.8h}, [x4], x1
ld1 {v19.8h}, [x9], x1
-transpose_4x8H v18, v16, v17, v19, v26, v27, v28, v29
+transpose_4x8H v18, v16, v17, v19, v26, v27, v28, v29
h264_loop_filter_chroma_intra_10
@@ -1045,7 +1045,7 @@ h_loop_filter_chroma420_intra_10:
ld1 {v19.4h}, [x4], x1
ld1 {v19.d}[1], [x9], x1
-transpose_4x8H v18, v16, v17, v19, v26, v27, v28, v29
+transpose_4x8H v18, v16, v17, v19, v26, v27, v28, v29
h264_loop_filter_chroma_intra_10
diff --git a/libavcodec/aarch64/h264qpel_neon.S
b/libavcodec/aarch64/h264qpel_neon.S
index 21906327cd..f4475d96f9 100644
--- a/libavcodec/aarch64/h264qpel_neon.S
+++ b/libavcodec/aarch64/h264qpel_neon.S
@@ -580,8 +580,8 @@ function \type\()_h264_qpel16_hv_lowpass_l2_neon
endfunc
.endm
-h264_qpel16_hv put
-h264_qpel16_hv avg
+h264_qpel16_hv put
+h264_qpel16_hv avg
.macro h264_qpel8 type
function ff_\type\()_h264_qpel8_mc10_neon, export=1
@@ -759,8 +759,8 @@ function ff_\type\()_h264_qpel8_mc33_neon, export=1
endfunc
.endm
-h264_qpel8 put
-h264_qpel8 avg
+h264_qpel8 put
+h264_qpel8 avg
.macro h264_qpel16 type
function ff_\type\()_h264_qpel16_mc10_neon, export=1
@@ -931,5 +931,5 @@ function ff_\type\()_h264_qpel16_mc33_neon, export=1
endfunc
.endm
-h264_qpel16 put
-h264_qpel16 avg
+h264_qpel16 put
+h264_qpel16 avg
diff --git a/libavcodec/aarch64/hevcdsp_idct_neon.S
b/libavcodec/aarch64/hevcdsp_idct_neon.S
index ba8a1ebaed..3cac6e6db9 100644
--- a/libavcodec/aarch64/hevcdsp_idct_neon.S
+++ b/libavcodec/aarch64/hevcdsp_idct_neon.S
@@ -239,23 +239,23 @@ function hevc_add_residual_32x32_16_neon, export=0
endfunc
.macro tr_4x4 in0, in1, in2, in3, out0, out1, out2, out3, shift
- sshll v20.4s, \in0, #6
- sshll v21.4s, \in0, #6
- smull v22.4s, \in1, v4.h[1]
- smull v23.4s, \in1, v4.h[3]
- smlal v20.4s, \in2, v4.h[0] //e0
- smlsl v21.4s, \in2, v4.h[0] //e1
- smlal v22.4s, \in3, v4.h[3] //o0
- smlsl v23.4s, \in3, v4.h[1] //o1
-
- addv24.4s, v20.4s, v22.4s
- subv20.4s, v20.4s, v22.4s
- addv22.4s, v21.4s, v23.4s
- subv21.4s, v21.4s, v23.4s
- sqrshrn\out0, v24.4s, #\shift
- sqrshrn\out3, v20.4s, #\shift
- sqrshrn\out1, v22.4s, #\shift
- sqrshrn\out2, v21.4s, #\shift
+sshll v20.4s, \in0, #6
+sshll v21.4s, \in0, #6
+smull v22.4s, \in1, v4.h[1]
+smull v23.4s, \in1, v4.h[3]
+smlal v20.4s, \in2, v4.h[0] //e0
+smlsl v21.4s, \in2, v4.h[0] //e1
+smlal v22.4s, \in3, v4.h[3] //o0
+smlsl v23.4s, \in3, v4.h[1] //o1
+
+add v24.4s, v20.4s, v22.4s
+sub v20.4s, v20.4s, v22.4s
+add v22.4s, v21.4s, v23.4s
+sub v21.4s, v21.4s, v23.4s
+sqrshrn \out0, v24.4s, #\shift
+
[FFmpeg-devel] [PATCH 4/5] aarch64: Manually tweak vertical alignment/indentation in tx_float_neon.S
Favour left aligned columns over right aligned columns.
In principle either style should be ok, but some of the cases
easily lead to incorrect indentation in the surrounding code (see
a couple of cases fixed up in the preceding patch), and show up in
automatic indentation correction attempts.
---
libavutil/aarch64/tx_float_neon.S | 120 +++---
1 file changed, 60 insertions(+), 60 deletions(-)
diff --git a/libavutil/aarch64/tx_float_neon.S
b/libavutil/aarch64/tx_float_neon.S
index 9916ad4142..30ffa2a1d4 100644
--- a/libavutil/aarch64/tx_float_neon.S
+++ b/libavutil/aarch64/tx_float_neon.S
@@ -733,12 +733,12 @@ FFT16_FN ns_float, 1
add x11, x1, x21, lsl #1
add x12, x1, x22
-ldp q0, q1, [x1, #((0 + \part)*32 + \off)]
-ldp q4, q5, [x1, #((2 + \part)*32 + \off)]
-ldp q2, q3, [x10, #((0 + \part)*32 + \off)]
-ldp q6, q7, [x10, #((2 + \part)*32 + \off)]
+ldp q0, q1, [x1, #((0 + \part)*32 + \off)]
+ldp q4, q5, [x1, #((2 + \part)*32 + \off)]
+ldp q2, q3, [x10, #((0 + \part)*32 + \off)]
+ldp q6, q7, [x10, #((2 + \part)*32 + \off)]
-ldp q8, q9, [x11, #((0 + \part)*32 + \off)]
+ldp q8, q9, [x11, #((0 + \part)*32 + \off)]
ldp q10, q11, [x11, #((2 + \part)*32 + \off)]
ldp q12, q13, [x12, #((0 + \part)*32 + \off)]
ldp q14, q15, [x12, #((2 + \part)*32 + \off)]
@@ -747,12 +747,12 @@ FFT16_FN ns_float, 1
v8, v9, v10, v11, v12, v13, v14, v15, \
x7, x8, x9, 0
-stp q0, q1, [x1, #((0 + \part)*32 + \off)]
-stp q4, q5, [x1, #((2 + \part)*32 + \off)]
-stp q2, q3, [x10, #((0 + \part)*32 + \off)]
-stp q6, q7, [x10, #((2 + \part)*32 + \off)]
+stp q0, q1, [x1, #((0 + \part)*32 + \off)]
+stp q4, q5, [x1, #((2 + \part)*32 + \off)]
+stp q2, q3, [x10, #((0 + \part)*32 + \off)]
+stp q6, q7, [x10, #((2 + \part)*32 + \off)]
-stp q8, q9, [x11, #((0 + \part)*32 + \off)]
+stp q8, q9, [x11, #((0 + \part)*32 + \off)]
stp q12, q13, [x11, #((2 + \part)*32 + \off)]
stp q10, q11, [x12, #((0 + \part)*32 + \off)]
stp q14, q15, [x12, #((2 + \part)*32 + \off)]
@@ -775,12 +775,12 @@ FFT16_FN ns_float, 1
add x12, x15, #((\part)*32 + \off)
add x13, x16, #((\part)*32 + \off)
-ldp q0, q1, [x10]
-ldp q4, q5, [x10, #(2*32)]
-ldp q2, q3, [x11]
-ldp q6, q7, [x11, #(2*32)]
+ldp q0, q1, [x10]
+ldp q4, q5, [x10, #(2*32)]
+ldp q2, q3, [x11]
+ldp q6, q7, [x11, #(2*32)]
-ldp q8, q9, [x12]
+ldp q8, q9, [x12]
ldp q10, q11, [x12, #(2*32)]
ldp q12, q13, [x13]
ldp q14, q15, [x13, #(2*32)]
@@ -800,10 +800,10 @@ FFT16_FN ns_float, 1
zip1v22.2d, v3.2d, v7.2d
zip2v23.2d, v3.2d, v7.2d
-ldp q0, q1, [x10, #(1*32)]
-ldp q4, q5, [x10, #(3*32)]
-ldp q2, q3, [x11, #(1*32)]
-ldp q6, q7, [x11, #(3*32)]
+ldp q0, q1, [x10, #(1*32)]
+ldp q4, q5, [x10, #(3*32)]
+ldp q2, q3, [x11, #(1*32)]
+ldp q6, q7, [x11, #(3*32)]
st1 { v16.4s, v17.4s, v18.4s, v19.4s }, [x10], #64
st1 { v20.4s, v21.4s, v22.4s, v23.4s }, [x11], #64
@@ -817,7 +817,7 @@ FFT16_FN ns_float, 1
zip1v26.2d, v11.2d, v15.2d
zip2v27.2d, v11.2d, v15.2d
-ldp q8, q9, [x12, #(1*32)]
+ldp q8, q9, [x12, #(1*32)]
ldp q10, q11, [x12, #(3*32)]
ldp q12, q13, [x13, #(1*32)]
ldp q14, q15, [x13, #(3*32)]
@@ -875,9 +875,9 @@ function ff_tx_fft32_\name\()_neon, export=1
SETUP_SR_RECOMB 32, x7, x8, x9
SETUP_LUT \no_perm
-LOAD_INPUT 0, 1, 2, 3, x2, \no_perm
-LOAD_INPUT 4, 5, 6, 7, x2, \no_perm
-LOAD_INPUT 8, 9, 10, 11, x2, \no_perm
+LOAD_INPUT 0, 1, 2, 3, x2, \no_perm
+LOAD_INPUT 4, 5, 6, 7, x2, \no_perm
+LOAD_INPUT 8, 9, 10, 11, x2, \no_perm
LOAD_INPUT 12, 13, 14, 15, x2, \no_perm
FF
Re: [FFmpeg-devel] [PATCH v2] doc: add spi.txt
On 17 Oct 2023, at 9:29, Stefano Sabatini wrote: > On date Monday 2023-10-16 06:34:45 +0200, Lynne wrote: >> Oct 16, 2023, 00:50 by mich...@niedermayer.cc: >> >>> This explains how to request refunds and what can be funded by SPI >>> >>> Co-Author: Stefano Sabatini >>> --- >>> doc/spi.txt | 73 + >>> 1 file changed, 73 insertions(+) >>> create mode 100644 doc/spi.txt >>> >>> diff --git a/doc/spi.txt b/doc/spi.txt >>> new file mode 100644 >>> index 00..ff4af8f42b >>> >> >> Again, I think this belongs on the website, not in our codebase. > > Given that this is a sort of internal memo, and that is targeted at > developers rather than final users, I see no value into exposing this > in the website (and we have similar documents - e.g. community.texi - > already in doc). > > OTOH given that this clarifies how donations are spent, there is also > a value into making this more transparent to users/donors, but I don't > see this as blocking (we can publish it here and then move it to the > website once the process has been consolidated). IMO this would be much more discoverable on the website, it would never occur to me to look for such information in the FFmpeg source tree doc folder. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@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 v1] avcodec/cbs: Keep ff_cbs_trace_syntax_element
> -Original Message-
> From: ffmpeg-devel On Behalf Of Mark
> Thompson
> Sent: Tuesday, October 17, 2023 5:14 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1] avcodec/cbs: Keep
> ff_cbs_trace_syntax_element
>
> On 10/10/2023 04:30, Dai, Jianhui J wrote:
> >> -Original Message-
> >> From: Dai, Jianhui J
> >> Sent: Tuesday, October 10, 2023 10:57 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: [PATCH v1] avcodec/cbs: Keep ff_cbs_trace_syntax_element
> >>
> >> Split ff_cbs_trace_syntax_element from ff_cbs_trace_read_log to
> >> decouple the tracing from GetBitContext. This allows CBS
> >> implementations that do not have a GetBitContext to directly use
> >> ff_cbs_trace_syntax_element to trace syntax elements.
> >>
> >> Signed-off-by: Jianhui Dai
> >> ---
> >> libavcodec/cbs.c | 41 +--
> >> libavcodec/cbs_internal.h | 4
> >> 2 files changed, 30 insertions(+), 15 deletions(-)
> >>
> >> diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c index
> >> cdd7adebeb..2f2cfcfb31
> >> 100644
> >> --- a/libavcodec/cbs.c
> >> +++ b/libavcodec/cbs.c
> >> @@ -498,26 +498,18 @@ void ff_cbs_trace_header(CodedBitstreamContext
> >> *ctx,
> >> av_log(ctx->log_ctx, ctx->trace_level, "%s\n", name); }
> >>
> >> -void ff_cbs_trace_read_log(void *trace_context,
> >> - GetBitContext *gbc, int length,
> >> - const char *str, const int *subscripts,
> >> - int64_t value)
> >> +void ff_cbs_trace_syntax_element(CodedBitstreamContext *ctx, int position,
> >> + const char *str, const int *subscripts,
> >> + const char *bits, int64_t value)
> >> {
> >> -CodedBitstreamContext *ctx = trace_context;
> >> char name[256];
> >> -char bits[256];
> >> size_t name_len, bits_len;
> >> int pad, subs, i, j, k, n;
> >> -int position;
> >> -
> >> -av_assert0(value >= INT_MIN && value <= UINT32_MAX);
> >>
> >> -position = get_bits_count(gbc);
> >> +if (!ctx->trace_enable)
> >> +return;
> >>
> >> -av_assert0(length < 256);
> >> -for (i = 0; i < length; i++)
> >> -bits[i] = get_bits1(gbc) ? '1' : '0';
> >> -bits[length] = 0;
> >> +av_assert0(value >= INT_MIN && value <= UINT32_MAX);
> >>
> >> subs = subscripts ? subscripts[0] : 0;
> >> n = 0;
> >> @@ -545,7 +537,7 @@ void ff_cbs_trace_read_log(void *trace_context,
> >> av_assert0(n == subs);
> >>
> >> name_len = strlen(name);
> >> -bits_len = length;
> >> +bits_len = strlen(bits);
> >>
> >> if (name_len + bits_len > 60)
> >> pad = bits_len + 2;
> >> @@ -556,6 +548,25 @@ void ff_cbs_trace_read_log(void *trace_context,
> >> position, name, pad, bits, value); }
> >>
> >> +void ff_cbs_trace_read_log(void *trace_context,
> >> + GetBitContext *gbc, int length,
> >> + const char *str, const int *subscripts,
> >> + int64_t value) {
> >> +CodedBitstreamContext *ctx = trace_context;
> >> +char bits[256];
> >> +int position;
> >> +
> >> +position = get_bits_count(gbc);
> >> +
> >> +av_assert0(length < 256);
> >> +for (int i = 0; i < length; i++)
> >> +bits[i] = get_bits1(gbc) ? '1' : '0';
> >> +bits[length] = 0;
> >> +
> >> +ff_cbs_trace_syntax_element(ctx, position, str, subscripts,
> >> +bits, value); }
> >> +
> >> void ff_cbs_trace_write_log(void *trace_context,
> >> PutBitContext *pbc, int length,
> >> const char *str, const int *subscripts,
> >> diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
> >> index 07220f1f3e..ff90ce467d 100644
> >> --- a/libavcodec/cbs_internal.h
> >> +++ b/libavcodec/cbs_internal.h
> >> @@ -158,6 +158,10 @@ typedef struct CodedBitstreamType { void
> >> ff_cbs_trace_header(CodedBitstreamContext *ctx,
> >>const char *name);
> >>
> >> +void ff_cbs_trace_syntax_element(CodedBitstreamContext *ctx, int position,
> >> + const char *name, const int *subscripts,
> >> + const char *bitstring, int64_t
> >> +value);
> >> +
> >>
> >> // Helper functions for read/write of common bitstream elements,
> >> including // generation of trace output. The simple functions are
> >> equivalent to
> >
> > @Mark Thompson
> > Could you please take a look if it's a valid change based on your last
> > refactor?
> > It's intended to use for the reviewing cbs_vp8 patch.
>
> The simple answer here is to forge a GetBitContext pointing at the right
> place, like
> the write tracing does.
>
> However: for your VP8 case, I'm a bit unclear why it isn't using get_bits
> already?
> The setup seems to be to stop normal parsing at the end of the uncompr
Re: [FFmpeg-devel] [PATCH] avformat/mxfenc: fix static building
tis 2023-09-19 klockan 17:12 +0200 skrev Michael Riedl: > MXF muxer requires rangecoder otherwise static linking fails. > > Signed-off-by: Michael Riedl Pushed /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4 0/3] lavc/libaribcaption.c: add MSZ characters related options
Re-send the patchset. The patches are same as v3, but its thread were corrupted. - This patch add MSZ (Middle Size; half width) characters related options and some fixes. As Jan suggested to PATCH v2, I split it into 3 patches, drop `#if`s, and bump required libaribcaption version to 1.1.1 (author preferred version). TADANO Tokumei (3): lavc/libaribcaption.c: FIX: change all `boot` option var to `int` lavc/libaribcaption.c: add MSZ characters related options lavc/libaribcaption.c: rename `-replace_fullwidth_ascii` option configure | 2 +- doc/decoders.texi | 28 ++-- libavcodec/libaribcaption.c | 28 +++- 3 files changed, 42 insertions(+), 16 deletions(-) -- 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] [PATCH v4 1/3] lavc/libaribcaption.c: FIX: change all `boot` option var to `int`
This patch fixes a bug in curret version.
On some environments, a `bool` variable is small space than `int`.
If a `bool` option was specified by command line, following
variables would be filled and may be destroyed by av_opt_copy().
This patch change all the `bool` option variables in
`ARIBCaptionContext` to `int`.
Signed-off-by: TADANO Tokumei
---
libavcodec/libaribcaption.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 8a8c8f8cfd..be3328c5c9 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -68,14 +68,14 @@ typedef struct ARIBCaptionContext {
int subtitle_type;
int encoding_scheme;
-bool ass_single_rect;
+int ass_single_rect;
char *font;
-bool replace_fullwidth_ascii;
-bool force_stroke_text;
-bool ignore_background;
-bool ignore_ruby;
+int replace_fullwidth_ascii;
+int force_stroke_text;
+int ignore_background;
+int ignore_ruby;
float stroke_width;
-bool replace_drcs;
+int replace_drcs;
int64_t pts;
AVRational time_base;
--
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] [PATCH v4 2/3] lavc/libaribcaption.c: add MSZ characters related options
This patch add MSZ (Middle Size; half width) characters related
options.
* add `-replace_msz_japanese` option introduced in version 1.0.1
of libaribcaption.
* add `-replace_msz_glyph` option introduced in version 1.1.0
of libaribcaption.
If specified fonts contain half-width glyphs (e.g., BIZ UDGothic),
it make better rendering with `-replace_msz_ascii false` and
`-replace_msz_japanese false` option for bitmap sub_type.
Signed-off-by: TADANO Tokumei
---
configure | 2 +-
doc/decoders.texi | 16
libavcodec/libaribcaption.c | 10 ++
3 files changed, 27 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index d203177a74..2fb827e1fb 100755
--- a/configure
+++ b/configure
@@ -6679,7 +6679,7 @@ enabled libaom&& require_pkg_config libaom
"aom >= 1.0.0" aom/aom_co
enabled libaribb24&& { check_pkg_config libaribb24 "aribb24 > 1.0.3"
"aribb24/aribb24.h" arib_instance_new ||
{ enabled gpl && require_pkg_config libaribb24
aribb24 "aribb24/aribb24.h" arib_instance_new; } ||
die "ERROR: libaribb24 requires version higher
than 1.0.3 or --enable-gpl."; }
-enabled libaribcaption&& require_pkg_config libaribcaption "libaribcaption
>= 0.1.0" "aribcaption/aribcaption.h" aribcc_context_alloc
+enabled libaribcaption&& require_pkg_config libaribcaption "libaribcaption
>= 1.1.1" "aribcaption/aribcaption.h" aribcc_context_alloc
enabled lv2 && require_pkg_config lv2 lilv-0 "lilv/lilv.h"
lilv_world_new
enabled libiec61883 && require libiec61883 libiec61883/iec61883.h
iec61883_cmp_connect -lraw1394 -lavc1394 -lrom1394 -liec61883
enabled libass&& require_pkg_config libass "libass >= 0.11.0"
ass/ass.h ass_library_init
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 09b8314dd2..36c3404475 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -459,6 +459,22 @@ Specify whether to render replaced DRCS characters as
Unicode characters.
The default is @var{true}.
+@item -replace_msz_japanese @var{boolean}
+Specify whether to replace some MSZ (Middle Size; half width) fullwidth
+japanese special characters with halfwidth ones.
+
+The default is @var{true}.
+
+@item -replace_msz_glyph @var{boolean}
+Specify whether to replace MSZ (Middle Size; half width) characters
+with halfwidth glyphs if the fonts supports it.
+This option works under FreeType or DirectWrite renderer
+with Adobe-Japan1 compliant fonts.
+e.g., IBM Plex Sans JP, Morisawa BIZ UDGothic, Morisawa BIZ UDMincho,
+Yu Gothic, Yu Mincho, and Meiryo.
+
+The default is @var{true}.
+
@item -canvas_size @var{image_size}
Specify the resolution of the canvas to render subtitles to; usually, this
should be frame size of input video.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index be3328c5c9..74822586dc 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -76,6 +76,8 @@ typedef struct ARIBCaptionContext {
int ignore_ruby;
float stroke_width;
int replace_drcs;
+int replace_msz_japanese;
+int replace_msz_glyph;
int64_t pts;
AVRational time_base;
@@ -1005,6 +1007,8 @@ static int aribcaption_init(AVCodecContext *avctx)
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
ctx->replace_fullwidth_ascii);
+aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
+ ctx->replace_msz_japanese);
/* Similar behavior as ffmpeg tool to set canvas size */
if (ctx->canvas_width > 0 && ctx->canvas_height > 0 &&
@@ -1057,6 +1061,8 @@ static int aribcaption_init(AVCodecContext *avctx)
aribcc_renderer_set_force_no_background(ctx->renderer,
ctx->ignore_background);
aribcc_renderer_set_force_no_ruby(ctx->renderer, ctx->ignore_ruby);
aribcc_renderer_set_stroke_width(ctx->renderer, ctx->stroke_width);
+aribcc_renderer_set_replace_msz_halfwidth_glyph(ctx->renderer,
+
ctx->replace_msz_glyph);
if (ctx->font) {
int is_nomem = 0;
size_t count = 0;
@@ -1144,6 +1150,10 @@ static const AVOption options[] = {
OFFSET(stroke_width), AV_OPT_TYPE_FLOAT, { .dbl = 1.5 }, 0.0, 3.0, SD },
{ "replace_drcs", "replace known DRCS [bitmap]",
OFFSET(replace_drcs), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_japanese", "replace MSZ fullwidth Japanese with halfwidth
[ass, bitmap]",
+ OFFSET(replace_msz_japanese), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_glyph", "replace MSZ characters with halfwidth glyphs
[bitmap]",
+ OFFSET(replace_msz_glyph), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{"canvas_size", "set input video size (WxH or abbreviation) [bitmap]",
OFFSET(can
[FFmpeg-devel] [PATCH v4 3/3] lavc/libaribcaption.c: rename `-replace_fullwidth_ascii` option
This patch renames `-replace_fullwidth_ascii` option to
`-replace_msz_ascii` to clarify option meaning.
Signed-off-by: TADANO Tokumei
---
doc/decoders.texi | 12 ++--
libavcodec/libaribcaption.c | 8
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 36c3404475..eb00e2a9e9 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -427,12 +427,6 @@ If your player cannot handle AVSubtitles with multiple ASS
rectangles properly,
set this option to @var{true} or define @env{ASS_SINGLE_RECT=1} to change
default behavior at compilation.
-@item -replace_fullwidth_ascii @var{boolean}
-Specify whether to replace MSZ (Middle Size, half width) fullwidth
-alphanumerics with halfwidth alphanumerics.
-
-The default is @var{true}.
-
@item -force_outline_text @var{boolean}
Specify whether always render outline text for all characters regardless of
the indication by charactor style.
@@ -459,6 +453,12 @@ Specify whether to render replaced DRCS characters as
Unicode characters.
The default is @var{true}.
+@item -replace_msz_ascii @var{boolean}
+Specify whether to replace MSZ (Middle Size; half width) fullwidth
+alphanumerics with halfwidth alphanumerics.
+
+The default is @var{true}.
+
@item -replace_msz_japanese @var{boolean}
Specify whether to replace some MSZ (Middle Size; half width) fullwidth
japanese special characters with halfwidth ones.
diff --git a/libavcodec/libaribcaption.c b/libavcodec/libaribcaption.c
index 74822586dc..2a058a4992 100644
--- a/libavcodec/libaribcaption.c
+++ b/libavcodec/libaribcaption.c
@@ -70,12 +70,12 @@ typedef struct ARIBCaptionContext {
int encoding_scheme;
int ass_single_rect;
char *font;
-int replace_fullwidth_ascii;
int force_stroke_text;
int ignore_background;
int ignore_ruby;
float stroke_width;
int replace_drcs;
+int replace_msz_ascii;
int replace_msz_japanese;
int replace_msz_glyph;
@@ -1006,7 +1006,7 @@ static int aribcaption_init(AVCodecContext *avctx)
return AVERROR_EXTERNAL;
}
aribcc_decoder_set_replace_msz_fullwidth_ascii(ctx->decoder,
-
ctx->replace_fullwidth_ascii);
+ ctx->replace_msz_ascii);
aribcc_decoder_set_replace_msz_fullwidth_japanese(ctx->decoder,
ctx->replace_msz_japanese);
@@ -1138,8 +1138,6 @@ static const AVOption options[] = {
OFFSET(ass_single_rect), AV_OPT_TYPE_BOOL, { .i64 = ASS_SINGLE_RECT },
0, 1, SD },
{ "font", "comma-separated font family [ass, bitmap]",
OFFSET(font), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD },
-{ "replace_fullwidth_ascii", "replace MSZ fullwidth alphanumerics with
halfwidth alphanumerics [ass, bitmap]",
- OFFSET(replace_fullwidth_ascii), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1,
SD },
{ "force_outline_text", "always render characters with outline [(ass),
bitmap]",
OFFSET(force_stroke_text), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, SD },
{ "ignore_background", "ignore rendering caption background [(ass),
bitmap]",
@@ -1150,6 +1148,8 @@ static const AVOption options[] = {
OFFSET(stroke_width), AV_OPT_TYPE_FLOAT, { .dbl = 1.5 }, 0.0, 3.0, SD },
{ "replace_drcs", "replace known DRCS [bitmap]",
OFFSET(replace_drcs), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
+{ "replace_msz_ascii", "replace MSZ fullwidth alphanumerics with halfwidth
alphanumerics [ass, bitmap]",
+ OFFSET(replace_msz_ascii), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{ "replace_msz_japanese", "replace MSZ fullwidth Japanese with halfwidth
[ass, bitmap]",
OFFSET(replace_msz_japanese), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, SD },
{ "replace_msz_glyph", "replace MSZ characters with halfwidth glyphs
[bitmap]",
--
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".
Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion
On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote: > On date Friday 2023-10-13 21:19:34 +0200, Michael Niedermayer wrote: > > Hi everyone > > > > I propose using 15k$ from SPI for funding sws cleanup work. > > this is substantially less than what people belive this needs (see IRC logs > > from yesterday or so) > > So it really is more a small price for a good deed and not proper payment. > > This of course is only available to competent developers. (exact rules or > > how thats determined > > would still need to be decided unless its a clear case) > > Also the exact outcome and goal would need to be discussed by the community > > and whoever > > does the work. > > But some goals would probably be to make sws > > * pleasent to work with > > * similar speed or faster > > * proper multithreading > > * proper full colorspace convertion not ignoring gamma, primaries, ... > > * clean / understandable modular design (maybe everything can be a "Filter" > > inside sws > > that get build into a chain) > > > > Proper payment (50k$ maybe) would be too much in relation to what SPI has > > ATM (150k$) > > > > Above all, this is just my oppinion, the actual SPI funding also would need > > to > > be approved by the community. This can happen after a specific volunteer > > comes forth > > or before, whichever way the community prefers. > > Leaving apart the technical details about the implementation, this > should be feasible within the SPI framework (although this would > involve some paperwork and delays due to that). > > It would be useful at this point to define the process to accept the > proposal and potential candidates. We have a technical committee which > might take the lead on that and probably have the last word on it, > since "approved by the community" is a bit vague and there is the risk > that there will be never an approval "from the community" because of > diverging views, or that we get stuck at the design level. I think there are several shades of this The community might simply have a consensus that X should be funded. We achieved this both for traval and hw in all or nearly all cases. And quite plausibly we will achieve this too for other cases Hypothetically the community might have a consensus some work should be funded but not agree on technical details. Here honestly i think the developer doing the work should be the main decission maker. She is the one doing the work, knowing the code best. And most likely its one of the FFmpeg team doing the work. The technical committee could be used if reviewer and author cannot agree. I think we should stir clear of a "Planned economy" where some group thats "distanced" from the actual work decides on fine details. These did not work very well in real economies and i doubt it would work well for technical design. Furthermore the person doing specific work really should be, when she does the work be the one with the best understanding of the code (otherwise we "hired" the wrong person) so to me it makes sense she also would make decissions on technical details. At the same time she also takes responsibility for teh decission ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Add init_program_date_time so start time can be specified
---
doc/muxers.texi | 3 +++
libavformat/hlsenc.c | 7 ++-
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index f6071484ff..87c19a5cb9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
@code{hls_time} option.
@item program_date_time
Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
+@item init_program_date_time
+Time to start program date time at.
+
@item second_level_segment_index
Makes it possible to use segment indexes as %%d in hls_segment_filename
expression
besides date/time values when strftime is on.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4ef84c05c1..474322cc21 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -28,6 +28,8 @@
#include
#endif
+#include "float.h"
+
#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/avstring.h"
@@ -212,6 +214,8 @@ typedef struct HLSContext {
int64_t recording_time;
int64_t max_seg_size; // every segment file max size
+double init_program_date_time;
+
char *baseurl;
char *vtt_format_options_str;
char *subtitle_filename;
@@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
char *p = NULL;
int http_base_proto = ff_is_http_proto(s->url);
int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
-double initial_program_date_time = av_gettime() / 100.0;
+double initial_program_date_time = hls->init_program_date_time ?
hls->init_program_date_time : av_gettime() / 100.0;
if (hls->use_localtime) {
pattern = get_default_pattern_localtime_fmt(s);
@@ -3141,6 +3145,7 @@ static const AVOption options[] = {
{"split_by_time", "split the hls segment by time which user set by
hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX, E,
"flags"},
{"append_list", "append the new segments into old hls segment list", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
{"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0, AV_OPT_TYPE_CONST,
{.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E, "flags"},
+{"init_program_date_time", "Time to start program date time at",
OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0, DBL_MAX,
E},
{"second_level_segment_index", "include segment index in segment filenames
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX, E, "flags"},
{"second_level_segment_duration", "include segment duration in segment
filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX, E, "flags"},
{"second_level_segment_size", "include segment size in segment filenames
when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX, E, "flags"},
--
2.39.2 (Apple Git-143)
___
ffmpeg-devel mailing list
ffmpeg-devel@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] SWS cleanup / SPI Funding Suggestion
> On Oct 17, 2023, at 7:36 AM, Michael Niedermayer > wrote: > > On Sat, Oct 14, 2023 at 07:53:04PM +0200, Stefano Sabatini wrote: >> >> It would be useful at this point to define the process to accept the >> proposal and potential candidates. We have a technical committee which >> might take the lead on that and probably have the last word on it, >> since "approved by the community" is a bit vague and there is the risk >> that there will be never an approval "from the community" because of >> diverging views, or that we get stuck at the design level. > > I think there are several shades of this > > The community might simply have a consensus that X should be funded. > We achieved this both for traval and hw in all or nearly all cases. > And quite plausibly we will achieve this too for other cases > > Hypothetically the community might have a consensus some work should > be funded but not agree on technical details. > Here honestly i think the developer doing the work should be the main > decission maker. She is the one doing the work, knowing the code best. > And most likely its one of the FFmpeg team doing the work. I think this makes sense for cases where there is easily reachable consensus. What happens when we can't easily reach consensus? For example it doesn't seem like we have consensus on funding improvements to swscale (compared to integrating a 3rd party library). Does that mean that work cannot get funded through SPI? This is where I think using the TC to make a decision where the community at large cannot reach consensus might be useful. It doesn't need to decide the fine technical points of how the work is done, but it can provide a useful mechanism to disagree and commit about whether the work should be done at all and provide the broad strokes (like improve swscale vs write a brand new library vs integrate some third party one). - Cosmin ___ ffmpeg-devel mailing list ffmpeg-devel@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/amfenc: Fix for windows imprecise sleep
The reason for using av_usleep() here is that AMF API doesn’t provide an
API for explicit wait. There are two modes to get output from encoder:
1. Polling with some sleep to avoid CPU thrashing – currently used in FFmpeg
2. Set timeout parameter on AMF encoder and QueryOutput call will block
till output is available or the timeout happens.
#2 is the preferable way but it is designed more to be used with a separate
polling thread. With a single-thread approach in FFmpeg, the use of timeout
can block input submission making things slower. This is even more
pronounced when B-frames are enabled and several inputs are needed to produce
the first output.
The condition of this sleep is in special events (primarily when amf input
queue is full), not the core loop part. During the experiments the cpu
increasing is about 2-4% or so, not a burst.
For low resolution encoding, these changes bring significant performance
improvement (about 15%). It will not bring improvement for high resolution
such as 4K.
Thanks,
Evgeny
вт, 17 окт. 2023 г. в 03:26, Zhao Zhili :
>
> > 在 2023年10月17日，上午5:24，Mark Thompson 写道：
> >
> > On 16/10/2023 10:13, Evgeny Pavlov wrote:
> >> This commit reduces the sleep time on Windows to improve AMF encoding
> >> performance on low resolution input videos.
> >> This fix is for Windows only, because sleep() function isn't
> >> very accurate on Windows OS.
> >> Fix for issue #10622
> >> Signed-off-by: Evgeny Pavlov
> >> ---
> >> libavcodec/amfenc.c | 4
> >> 1 file changed, 4 insertions(+)
> >> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> >> index 061859f85c..0c95465d6e 100644
> >> --- a/libavcodec/amfenc.c
> >> +++ b/libavcodec/amfenc.c
> >> @@ -770,7 +770,11 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> AVPacket *avpkt)
> >> if (query_output_data_flag == 0) {
> >> if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain
> || (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >=
> ctx->hwsurfaces_in_queue_max)) {
> >> block_and_wait = 1;
> >> +#ifdef _WIN32
> >> +av_usleep(0); //Sleep() is not precise on Windows OS.
> >> +#else
> >> av_usleep(1000);
> >> +#endif
> >> }
> >> }
> >> } while (block_and_wait);
> >
> > Wasting lots of power by spinning on a CPU core does not seem like a
> good answer to this problem. (I mean, presumably that is why Windows isn't
> honouring your request for a short sleep, because it wants timers to have
> larger gaps to avoid wasting power.)
>
> If av_usleep is implemented via Sleep like current case, sleep 0 means
> yield current thread, so it’s not busy wait in normal case (but it can be
> busy wait).
>
> av_usleep(500) may looks better and do the same job by depending 500/1000
> = 0.
>
> I agree use sleep without real async is like a bug.
>
> >
> > Why is there a sleep here at all, anyway? An API for hardware encoding
> should be providing a way for the caller to wait for an outstanding
> operation to complete.
> >
> > 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 mailing list
> ffmpeg-devel@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/amfenc: 10 bit support, v4, 1/3] avcodec/amfenc: Fixes the color information in the output.
On Mon, Oct 16, 2023 at 11:41 PM Mark Thompson wrote:
> On 09/10/2023 10:52, Evgeny Pavlov wrote:
> > From: Michael Fabian 'Xaymar' Dirks
> >
> > added 10 bit support for amf hevc.
> >
> > before:
> >
> > command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va
> -hwaccel_output_format d3d11 -i test_10bit_file.mkv -an -c:v h264_amf
> res.dx11_hw_h264.mkv
> > output - Format of input frames context (p010le) is not supported by
> AMF.
> > command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va
> -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v hevc_amf
> res.dx11_hw_hevc.mkv
> > output - Format of input frames context (p010le) is not supported by
> AMF.
> >
> > after:
> >
> > command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va
> -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v h264_amf
> res.dx11_hw_h264.mkv
> > output - 10-bit input video is not supported by AMF H264 encoder
> > command - ffmpeg.exe -hide_banner -y -hwaccel d3d11va
> -hwaccel_output_format d3d11 -i test_10bit_file -an -c:v hevc_amf
> res.dx11_hw_hevc.mkv
> > output - 10bit file
> >
> > v2 - lost line returned in ff_amf_pix_fmts
> > v3 - fixes after review
> > v4 - extract duplicated code, fix incorrect processing of 10-bit input
> for h264
> >
> > Co-authored-by: Evgeny Pavlov
> > ---
> > libavcodec/amfenc.c | 37 +
> > libavcodec/amfenc.h | 3 +++
> > libavcodec/amfenc_h264.c | 24
> > libavcodec/amfenc_hevc.c | 26 +-
> > 4 files changed, 85 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> > index 061859f85c..0bd15dd812 100644
> > --- a/libavcodec/amfenc.c
> > +++ b/libavcodec/amfenc.c
> > @@ -60,6 +60,7 @@ const enum AVPixelFormat ff_amf_pix_fmts[] = {
> > #if CONFIG_DXVA2
> > AV_PIX_FMT_DXVA2_VLD,
> > #endif
> > +AV_PIX_FMT_P010,
> > AV_PIX_FMT_NONE
> > };
> >
> > @@ -72,6 +73,7 @@ static const FormatMap format_map[] =
> > {
> > { AV_PIX_FMT_NONE, AMF_SURFACE_UNKNOWN },
> > { AV_PIX_FMT_NV12, AMF_SURFACE_NV12 },
> > +{ AV_PIX_FMT_P010, AMF_SURFACE_P010 },
> > { AV_PIX_FMT_BGR0, AMF_SURFACE_BGRA },
> > { AV_PIX_FMT_RGB0, AMF_SURFACE_RGBA },
> > { AV_PIX_FMT_GRAY8, AMF_SURFACE_GRAY8 },
> > @@ -785,6 +787,41 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> AVPacket *avpkt)
> > return ret;
> > }
> >
> > +int ff_amf_get_color_profile(AVCodecContext *avctx)
> > +{
> > +amf_int64 color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_UNKNOWN;
>
> Can you explain what this CONVERTER_COLOR_PROFILE option is actually doing?
>
> You've passed the primaries and transfer function to AMF options later on,
> but this seems to then only consider a subset of possible matrices rather
> than just passing that through as well to write into the VUI metadata. Why?
>
> (If this isn't supported by AMF then a more correct solution might be to
> insert a metadata BSF to edit the correct values into the output stream
> after it has been encoded.)
>
> When RGB surface is submitted, AMF encoder not only writes VUI header but
also does color conversion. In this case CONVERTER_COLOR_PROFILE defines
color conversion matrix. This conversion may happen with shaders or inside
VCN if it is capable to do so.
These are input parameters for conversion – if conversion is involved:
AMF_VIDEO_ENCODER_INPUT_COLOR_PROFILE – for color conversion: limited
number of color spaces is supported.
AMF_VIDEO_ENCODER_INPUT_TRANSFER_CHARACTERISTIC
AMF_VIDEO_ENCODER_INPUT_COLOR_PRIMARIES
AMF_VIDEO_ENCODER_INPUT_HDR_METADATA
These are output parameters for conversion and data for VUI:
AMF_VIDEO_ENCODER_OUTPUT_COLOR_PROFILE – for VUI only, used if color
conversion is done outside of AMF
AMF_VIDEO_ENCODER_OUTPUT_TRANSFER_CHARACTERISTIC
AMF_VIDEO_ENCODER_OUTPUT_COLOR_PRIMARIES
AMF_VIDEO_ENCODER_OUTPUT_HDR_METADATA
It would be possible to add unsupported color matrices via editing VUI in
the output stream but it is better to do it via a separate patch as
supported covers most common use cases.
> > +if (avctx->color_range == AVCOL_RANGE_JPEG) {
> > +/// Color Space for Full (JPEG) Range
> > +switch (avctx->colorspace) {
> > +case AVCOL_SPC_SMPTE170M:
> > +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_601;
> > +break;
> > +case AVCOL_SPC_BT709:
> > +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_709;
> > +break;
> > +case AVCOL_SPC_BT2020_NCL:
> > +case AVCOL_SPC_BT2020_CL:
> > +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_FULL_2020;
> > +break;
> > +}
> > +} else {
> > +/// Color Space for Limited (MPEG) range
> > +switch (avctx->colorspace) {
> > +case AVCOL_SPC_SMPTE170M:
> > +color_profile = AMF_VIDEO_CONVERTER_COLOR_PROFILE_601;
Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion
On 10/14/2023 2:53 PM, Stefano Sabatini wrote: On date Friday 2023-10-13 21:19:34 +0200, Michael Niedermayer wrote: Hi everyone I propose using 15k$ from SPI for funding sws cleanup work. this is substantially less than what people belive this needs (see IRC logs from yesterday or so) So it really is more a small price for a good deed and not proper payment. This of course is only available to competent developers. (exact rules or how thats determined would still need to be decided unless its a clear case) Also the exact outcome and goal would need to be discussed by the community and whoever does the work. But some goals would probably be to make sws * pleasent to work with * similar speed or faster * proper multithreading * proper full colorspace convertion not ignoring gamma, primaries, ... * clean / understandable modular design (maybe everything can be a "Filter" inside sws that get build into a chain) Proper payment (50k$ maybe) would be too much in relation to what SPI has ATM (150k$) Above all, this is just my oppinion, the actual SPI funding also would need to be approved by the community. This can happen after a specific volunteer comes forth or before, whichever way the community prefers. Leaving apart the technical details about the implementation, this should be feasible within the SPI framework (although this would involve some paperwork and delays due to that). It would be useful at this point to define the process to accept the proposal and potential candidates. We have a technical committee which might take the lead on that and probably have the last word on it, since "approved by the community" is a bit vague and there is the risk that there will be never an approval "from the community" because of diverging views, or that we get stuck at the design level. "Approved by the community" would probably mean a vote by the GA if there's no clear consensus. The technical committee should be left as a last resort, as usual, when there are two completely opposing views and no way to convince either party of the alternative. As a start, probably there should be a design doc somewhere, discussed by the community and finally approved (by the technical committee??) before we present the request and candidate to SPI. In fact probably the design doc is the first thing a candidate might need to work on. Also I'd avoid terms such as "rewrite" or "cleanup" since they have bad connotations, maybe let's call it "review" or "refinement". ___ ffmpeg-devel mailing list ffmpeg-devel@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] SWS cleanup / SPI Funding Suggestion
Le perjantaina 13. lokakuuta 2023, 22.19.34 EEST Michael Niedermayer a écrit : > But some goals would probably be to make sws > * pleasent to work with > * similar speed or faster > * proper multithreading > * proper full colorspace convertion not ignoring gamma, primaries, ... > * clean / understandable modular design (maybe everything can be a "Filter" > inside sws that get build into a chain) It sounds very nice. But it also sounds very fuzzy and subjective. Unless you can put this in more objective terms such as would be expected of a statement of work, all the while not compromising the intent of the sponsorship, I would advise against using foundation funds. But first... > Proper payment (50k$ maybe) would be too much in relation to what SPI has > ATM (150k$) In my opinion, not "paying properly" is morally wrong, and sets a very bad example that it is acceptable not to pay developers properly. Also it is really not that much money. I suppose that the yearly revenues are even only a fraction of that balance. If so, I would argue that it is not financially reasonable, doubly so when the overall world economy is in a rather iffy situation. If it were up to me, I would keep that money for infrastructure and other fees, purposeful hardware donations and travel. Lastly using foundation funds to sponsor specific project may open a pandora box. What happens if more than one credible developer wants to take up the project? Or if other developers demand that their other reasonable clean-up projects be funded too? If the revenue and balance were much higher, you could hire all of them. But you can't, and then the simplest and safest way to avoid moral hazards is to hire nobody. N.B.: I am not part of the GA, and I have neither the expertise and credibility nor the time and motivation to take up this project, so that's just my free advice. -- Rémi Denis-Courmont http://www.remlab.net/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/amfenc: Fix for windows imprecise sleep
On Tue, 17 Oct 2023 at 19:34, Evgeny Pavlov wrote:
>
> The reason for using av_usleep() here is that AMF API doesn’t provide an
> API for explicit wait. There are two modes to get output from encoder:
>
> 1. Polling with some sleep to avoid CPU thrashing – currently used in FFmpeg
>
> 2. Set timeout parameter on AMF encoder and QueryOutput call will block
> till output is available or the timeout happens.
>
> #2 is the preferable way but it is designed more to be used with a separate
> polling thread. With a single-thread approach in FFmpeg, the use of timeout
> can block input submission making things slower. This is even more
> pronounced when B-frames are enabled and several inputs are needed to produce
> the first output.
>
> The condition of this sleep is in special events (primarily when amf input
> queue is full), not the core loop part. During the experiments the cpu
> increasing is about 2-4% or so, not a burst.
>
> For low resolution encoding, these changes bring significant performance
> improvement (about 15%). It will not bring improvement for high resolution
> such as 4K.
>
>
> Thanks,
>
> Evgeny
>
> вт, 17 окт. 2023 г. в 03:26, Zhao Zhili :
>
> >
> > > 在 2023年10月17日，上午5:24，Mark Thompson 写道：
> > >
> > > On 16/10/2023 10:13, Evgeny Pavlov wrote:
> > >> This commit reduces the sleep time on Windows to improve AMF encoding
> > >> performance on low resolution input videos.
> > >> This fix is for Windows only, because sleep() function isn't
> > >> very accurate on Windows OS.
> > >> Fix for issue #10622
> > >> Signed-off-by: Evgeny Pavlov
> > >> ---
> > >> libavcodec/amfenc.c | 4
> > >> 1 file changed, 4 insertions(+)
> > >> diff --git a/libavcodec/amfenc.c b/libavcodec/amfenc.c
> > >> index 061859f85c..0c95465d6e 100644
> > >> --- a/libavcodec/amfenc.c
> > >> +++ b/libavcodec/amfenc.c
> > >> @@ -770,7 +770,11 @@ int ff_amf_receive_packet(AVCodecContext *avctx,
> > AVPacket *avpkt)
> > >> if (query_output_data_flag == 0) {
> > >> if (res_resubmit == AMF_INPUT_FULL || ctx->delayed_drain
> > || (ctx->eof && res_query != AMF_EOF) || (ctx->hwsurfaces_in_queue >=
> > ctx->hwsurfaces_in_queue_max)) {
> > >> block_and_wait = 1;
> > >> +#ifdef _WIN32
> > >> +av_usleep(0); //Sleep() is not precise on Windows OS.
> > >> +#else
> > >> av_usleep(1000);
> > >> +#endif
> > >> }
> > >> }
> > >> } while (block_and_wait);
> > >
> > > Wasting lots of power by spinning on a CPU core does not seem like a
> > good answer to this problem. (I mean, presumably that is why Windows isn't
> > honouring your request for a short sleep, because it wants timers to have
> > larger gaps to avoid wasting power.)
> >
> > If av_usleep is implemented via Sleep like current case, sleep 0 means
> > yield current thread, so it’s not busy wait in normal case (but it can be
> > busy wait).
> >
> > av_usleep(500) may looks better and do the same job by depending 500/1000
> > = 0.
> >
> > I agree use sleep without real async is like a bug.
> >
> > >
> > > Why is there a sleep here at all, anyway? An API for hardware encoding
> > should be providing a way for the caller to wait for an outstanding
> > operation to complete.
> > >
> > > 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 mailing list
> > ffmpeg-devel@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".
Please don't top-post. I'll bottom-post now and no one will know how
to read this email.
If you need more precise sleep on Windows, your application should use
timeBeginPeriod/timeEndPeriod API, see
https://learn.microsoft.com/en-us/windows/win32/api/timeapi/nf-timeapi-timebeginperiod
This sleep shouldn't be there to begin with and removing it only for
Windows, seems like a hacky workaround.
Sleep on Windows is accurate, when you request a timer resolution
appropriate for your application. You probably don't do that, and have
unexpectedly long sleeps, but it is not because they are "not
accurate", it is because you don't ask for it.
Side note, with `Sleep()` you can request only 1 ms sleep, but with
with waitable timers
https://learn.microsoft.com/en-us/windows/win32/sync/waitable-timer-objects
you can go down to 0.5 ms, which seems currently be the lowest
interval that Windows kernel will wake anything up
Re: [FFmpeg-devel] SWS cleanup / SPI Funding Suggestion
On Tue, Oct 17, 2023 at 09:50:41PM +0300, Rémi Denis-Courmont wrote: > Le perjantaina 13. lokakuuta 2023, 22.19.34 EEST Michael Niedermayer a écrit : > > But some goals would probably be to make sws > > * pleasent to work with > > * similar speed or faster > > * proper multithreading > > * proper full colorspace convertion not ignoring gamma, primaries, ... > > * clean / understandable modular design (maybe everything can be a "Filter" > > inside sws that get build into a chain) > > It sounds very nice. But it also sounds very fuzzy and subjective. Unless you > can put this in more objective terms such as would be expected of a statement > of work, all the while not compromising the intent of the sponsorship, I > would > advise against using foundation funds. What i had in mind was that the developer who wants to work on this would provide a offer that is more clearly defined. > > But first... > > > Proper payment (50k$ maybe) would be too much in relation to what SPI has > > ATM (150k$) > > In my opinion, not "paying properly" is morally wrong, and sets a very bad > example that it is acceptable not to pay developers properly. It can be "proper" depending on where the developer is from, what she exactly will do and how much time she will need. Also the developer may have other sources of payment for this work or may benefit from a better swscale directly or want to work on this volunteerly and just needs a little extra push. I dont think its correct to view this in isolation as a commercial US based software development contract. (i did make this mistake) > > Also it is really not that much money. I suppose that the yearly revenues are > even only a fraction of that balance. If so, I would argue that it is not > financially reasonable, doubly so when the overall world economy is in a > rather > iffy situation. If it were up to me, I would keep that money for > infrastructure > and other fees, purposeful hardware donations and travel. all the SPI money stuff is public. But IMO the really important part is a different one. Not how much money we have in SPI from donations today. But how much we could have if we USE the money. Why would someone donate to FFmpeg ? we have enough money for hw & travel. If we use it to improve FFmpeg suddenly there is a reason to donate and also theres a reason for us to ask for donations. Only when we use the money and actively seek donations can we know what amount of money would be available. Also not using the money ever is almost certainly not what the people donating wanted. And many different developers did over the last years indicate the need for more solid financial sustainability. both SPI and FFlabs can be a parts in this. Rejecting SPI seems not wise. Having multiple sources of funding seems a good thing. > > Lastly using foundation funds to sponsor specific project may open a pandora > box. FFlabs opened that already i think > What happens if more than one credible developer wants to take up the > project? Then 15k$ was too much > Or if other developers demand that their other reasonable clean-up > projects be funded too? they should ask IMHO > If the revenue and balance were much higher, you could > hire all of them. But you can't, and then the simplest and safest way to > avoid > moral hazards is to hire nobody. Let us all starve because if we start fishing and eating fish it might just be that there are not enough fish Whats the worst that can happen ? We fund a few projects, we ask for donations a slight bit more actively, maybe a news entry on the webpage pointing to what work was possible from donations. and it doesnt work out and our funds decrease from 120k with funding 5+ projects to 60k. and at that point we return to hw and travel only use of the money > > N.B.: I am not part of the GA, and I have neither the expertise and > credibility nor the time and motivation to take up this project, so that's > just my free advice. your comments have always been interresting, even if i might disagree with them ! thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. 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] SWS cleanup / SPI Funding Suggestion
On Tue, Oct 17, 2023 at 11:57:45PM +0200, Michael Niedermayer wrote: > On Tue, Oct 17, 2023 at 09:50:41PM +0300, Rémi Denis-Courmont wrote: [...] > > If the revenue and balance were much higher, you could > > hire all of them. But you can't, and then the simplest and safest way to > > avoid > > moral hazards is to hire nobody. > > Let us all starve because if we start fishing and eating fish it might just be > that there are not enough fish > > Whats the worst that can happen ? > We fund a few projects, we ask for donations a slight bit more actively, > maybe a news entry on the webpage pointing to what work was possible from > donations. > and it doesnt work out and our funds decrease from 120k with funding 5+ > projects > to 60k. and at that point we return to hw and travel only use of the money that should have been 150k (which is what we have curently) and 100k (where i think we should rethink funding projects IF donations do not increase to make us cashflow neutral) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The day soldiers stop bringing you their problems is the day you have stopped leading them. They have either lost confidence that you can help or concluded you do not care. Either case is a failure of leadership. - Colin Powell signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [RFC] A file format to store generic raw image/video files
# RFC: A file format to store generic raw image/video files Context: Developers and researchers often want to use raw image/video files, as they avoid the effects of encoding. Dealing with raw image/video files is typically done using raw files. This is an operational pain point, as the metadata about the file needs to be carried out on the side. Raw video/image metadata includes (at least) pixel format (aka `pix_fmt`), width, height, framerate, and others. For example, in order to read a specific rgba file that I got from a shader, I need to write: ``` $ ffmpeg -y -f rawvideo -video_size 1920x1080 -pix_fmt rgba -i post_shader.1920x1080.rgba -vf scale="out_color_matrix=bt601" out.png ``` # Y4M: A YUV, Planar Raw File Format This problem has been partially addressed in [y4m](https://wiki.multimedia.cx/index.php/YUV4MPEG2). y4m is a raw (uncompressed), annotated image/video format for YUV content. It supports both images and video (a set of consecutive frames). It also supports framerates, interlaced/progressive content, aspect, location of subsampled chroma planes, and color ranges. The main limitation of y4m is that it only supports a reduced set of planar, 8-bit, YUV formats (444, 422, 420): yuv420p, yuv422p, and yuv444p. # R4M: A Generic Raw File Format We propose a new raw image/video format, R4M, that extends Y4M to support: * (a) every `pix_fmt` that ffmpeg supports. The implementation would support generic AVPixFmtDescriptor's, so any new pixel format based on it will be automatically supported. This includes planar/packed/semiplanar, yuv/rgb/bayer, and others. * (b) different bit sizes (this is part of `pix_fmt`), * (c) strides (pixel, row, plane), to allow devices to just dump their buffers directly, and * (d) flexible color information (h273, ICC, etc.). # Details R4M should support any raw image/video format that can be used by ffmpeg. R4M would keep the current Y4M features. * (1) support all y4m image settings * width * height * progressive/interlaced (top/bottom field first)/mixed mode * aspect ratio * chroma subsampling [implicit in `pix_fmt`] * chroma location * XYSCSS=420JPEG [this is the same than chroma subsampling + chroma location] * color range [implicit in color info] * (2) support all y4m video settings * framerates (as ratio) In terms of implementation, R4M would keep the Y4M format structure: text-based (readable) per-file and per-frame text headers, followed by explicitly-sized, per-frame, binary dumps of each frame. In terms of file format, we would keep the text-based header format (with a different header ID). As for the field list, we would add a human-readable dump of the `AVPixFmtDescriptor` struct, and remove the fields that are implicit in the `AVPixFmtDescriptor` dump (e.g. remove the "C" (colorspace) item). R4M would add the following new features: * (3) support every `pix_fmt` in ffmpeg (including planar/packed/semiplanar, yuv/rgb/bayer, etc.), and in general any `pix_fmt` representable using a `AVPixFmtDescriptor` struct. * planar/packed/semiplanar * yuv/rgb/bayer * (4) support different bitsizes [implicit on `pix_fmt`] * 8/9/10/12/14/16-bit color/other * little-endian/big-endian * float formats * (5) support image strides [implicit on `pix_fmt`] * pixel stride * row stride * plane stride * different values for different planes (e.g. Y, U, V, UV) * (6) support for flexible color information (a set of new fields). * h273: cp, tc, mc, range * ICC profile (restricted/unrestricted) * nclx (jpeg-xr color definition, ISO/IEC 29199-2/T.832) * (7) dynamic per-frame values * goal is to support videos where e.g. the resolution changes in the middle * support per-FRAME settings In terms of implementation, the suggestion is to write a thin library inside ffmpeg that can read from R4M files to ffmpeg buffers, and that can write from ffmpeg buffers to R4M files. An alternative is doing it as an external library. Rationale for in-ffmpeg library is this approach will make the code easier to land and better integrated with ffmpeg. In fact, this is how ffmpeg supports y4m right now (libavformat/yuv4mpeg* instead of any of the y4m libraries around). There is some value in an external library that supports it (e.g. I'd be interested in adding imlib2 support at some point, as I use it for quickly seeing images using feh), but I expect the source of truth to be what ffmpeg has. This is IMO the case for y4m. # Q&A Q1: Would this new format be acceptable in ffmpeg? If so, I could write a more detailed proposal with the R4M format, following the guidelines suggested here. Q2: Anybody has any other suggestion for a feature that should be added for a raw image/video file format? Q3: Anybody is interested in collaborating with the format? I would be more than happy to use a github repo for the format description. Thanks, -Chema ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org ht
Re: [FFmpeg-devel] [RFC] A file format to store generic raw image/video files
Chema Gonzalez via ffmpeg-devel (12023-10-17): > # RFC: A file format to store generic raw image/video files > > Context: Developers and researchers often want to use raw image/video > files, as they avoid the effects of encoding. Dealing with raw Looks like a XY problem. > We propose a new raw image/video format, R4M, that extends Y4M to support: Please explain why you think storing raw video or any other lossless codec into a standard container format like Matroska or Nut does not satisfy your needs. > * (a) every `pix_fmt` that ffmpeg supports. The implementation would > support generic AVPixFmtDescriptor's, so any new pixel format based on > it will be automatically supported. This includes > planar/packed/semiplanar, yuv/rgb/bayer, and others. This does not make any sense. Please mediate on the fundamental difference between in-memory representations and permanent storage representations. PS: do not Cc me. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/mxfdec: Check klv offset
Fixes: Assertion klv_offset >= mxf->run_in failed at libavformat/mxfdec.c:736
Fixes:
62936/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-5778404366221312.fuzz
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mxfdec.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 68939091e6..f2ec508b72 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -458,12 +458,15 @@ static int mxf_read_sync(AVIOContext *pb, const uint8_t
*key, unsigned size)
return i == size;
}
-static int klv_read_packet(KLVPacket *klv, AVIOContext *pb)
+static int klv_read_packet(MXFContext *mxf, KLVPacket *klv, AVIOContext *pb)
{
int64_t length, pos;
if (!mxf_read_sync(pb, mxf_klv_key, 4))
return AVERROR_INVALIDDATA;
klv->offset = avio_tell(pb) - 4;
+if (klv->offset < mxf->run_in)
+return AVERROR_INVALIDDATA;
+
memcpy(klv->key, mxf_klv_key, 4);
avio_read(pb, klv->key + 4, 12);
length = klv_decode_ber_length(pb);
@@ -3435,7 +3438,7 @@ static int mxf_seek_to_previous_partition(MXFContext *mxf)
/* Make sure this is actually a PartitionPack, and if so parse it.
* See deadlock2.mxf
*/
-if ((ret = klv_read_packet(&klv, pb)) < 0) {
+if ((ret = klv_read_packet(mxf, &klv, pb)) < 0) {
av_log(mxf->fc, AV_LOG_ERROR, "failed to read PartitionPack KLV\n");
return ret;
}
@@ -3712,7 +3715,7 @@ static void mxf_read_random_index_pack(AVFormatContext *s)
if (length < min_rip_length || length > max_rip_length)
goto end;
avio_seek(s->pb, file_size - length, SEEK_SET);
-if (klv_read_packet(&klv, s->pb) < 0 ||
+if (klv_read_packet(mxf, &klv, s->pb) < 0 ||
!IS_KLV_KEY(klv.key, ff_mxf_random_index_pack_key))
goto end;
if (klv.next_klv != file_size || klv.length <= 4 || (klv.length - 4) % 12)
{
@@ -3759,7 +3762,7 @@ static int mxf_read_header(AVFormatContext *s)
while (!avio_feof(s->pb)) {
const MXFMetadataReadTableEntry *metadata;
-ret = klv_read_packet(&klv, s->pb);
+ret = klv_read_packet(mxf, &klv, s->pb);
if (ret < 0 || IS_KLV_KEY(klv.key, ff_mxf_random_index_pack_key)) {
if (ret >= 0 && avio_size(s->pb) > klv.next_klv)
av_log(s, AV_LOG_WARNING, "data after the RandomIndexPack,
assuming end of file\n");
@@ -4011,7 +4014,7 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
*pkt)
if (pos < mxf->current_klv_data.next_klv -
mxf->current_klv_data.length || pos >= mxf->current_klv_data.next_klv) {
mxf->current_klv_data = (KLVPacket){{0}};
-ret = klv_read_packet(&klv, s->pb);
+ret = klv_read_packet(mxf, &klv, s->pb);
if (ret < 0)
break;
max_data_size = klv.length;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/hevc_ps: Dont leave invalid cpb_cnt_minus1 in the context
Fixes: index 32 out of bounds for type 'uint32_t [32]'
Fixes:
63003/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-4685160840560640
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_ps.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index a6b64b92e3..f4365ef5b5 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -421,6 +421,7 @@ static int decode_hrd(GetBitContext *gb, int
common_inf_present,
if (hdr->cpb_cnt_minus1[i] > 31) {
av_log(NULL, AV_LOG_ERROR, "nb_cpb %d invalid\n",
hdr->cpb_cnt_minus1[i]);
+hdr->cpb_cnt_minus1[i] = 0;
return AVERROR_INVALIDDATA;
}
}
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] A file format to store generic raw image/video files
Oct 18, 2023, 00:12 by ffmpeg-devel@ffmpeg.org: > # RFC: A file format to store generic raw image/video files > > Context: Developers and researchers often want to use raw image/video > files, as they avoid the effects of encoding. Dealing with raw > image/video files is typically done using raw files. This is an > operational pain point, as the metadata about the file needs to be > carried out on the side. Raw video/image metadata includes (at least) > pixel format (aka `pix_fmt`), width, height, framerate, and others. > > For example, in order to read a specific rgba file that I got from a > shader, I need to write: > ``` > $ ffmpeg -y -f rawvideo -video_size 1920x1080 -pix_fmt rgba -i > post_shader.1920x1080.rgba -vf scale="out_color_matrix=bt601" out.png > ``` > There's already NUT, which does all this. It is a documented standard, it has a reference library outside of FFmpeg, and built-in support. https://git.ffmpeg.org/gitweb/nut.git/blob/HEAD:/docs/nut.txt Also, I've been working on AVTransport, https://github.com/cyanreg/avtransport/blob/master/draft-avtransport-spec.md Which has all of this, plus much more. Additionally, Y4M has already been extended, and can be arbitrarily extended. It even does chroma positions now. These three containers cover pretty much all niches - from simple container anyone can write out in 30 minutes, to something slightly more complicated that isn't too difficult to write by copy-pasting, to something that requires a little more copy pasting to write out a simple stream. I don't think there's room for anything in between. Especially now that ISOBMFF also has an uncompressed mode, for which we've had requests to implement. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add init_program_date_time so start time can be specified
On 17 Oct 2023, at 17:51, Dave Johansen wrote:
> ---
> doc/muxers.texi | 3 +++
> libavformat/hlsenc.c | 7 ++-
> 2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index f6071484ff..87c19a5cb9 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> @item program_date_time
> Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
>
> +@item init_program_date_time
> +Time to start program date time at.
> +
> @item second_level_segment_index
> Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> besides date/time values when strftime is on.
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 4ef84c05c1..474322cc21 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -28,6 +28,8 @@
> #include
> #endif
>
> +#include "float.h"
> +
> #include "libavutil/avassert.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/avstring.h"
> @@ -212,6 +214,8 @@ typedef struct HLSContext {
> int64_t recording_time;
> int64_t max_seg_size; // every segment file max size
>
> +double init_program_date_time;
> +
> char *baseurl;
> char *vtt_format_options_str;
> char *subtitle_filename;
> @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
> char *p = NULL;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> -double initial_program_date_time = av_gettime() / 100.0;
> +double initial_program_date_time = hls->init_program_date_time ?
> hls->init_program_date_time : av_gettime() / 100.0;
>
> if (hls->use_localtime) {
> pattern = get_default_pattern_localtime_fmt(s);
> @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
> {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> {"append_list", "append the new segments into old hls segment list", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E, "flags"},
> {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0, DBL_MAX,
> E},
This should probably not be mixed into the flags options list.
It seems odd to have the user provide a double here instead of a ISO 8601
datetime, which is what the spec requires / ends up in the playlist.
If you do not want to handle the datetime string parsing, at least it would be
good to give a hint what exactly the double value is expected to be here.
However usability-wise I would prefer to accept a proper date/time here…
> {"second_level_segment_index", "include segment index in segment
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_INDEX }, 0, UINT_MAX, E, "flags"},
> {"second_level_segment_duration", "include segment duration in segment
> filenames when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_DURATION }, 0, UINT_MAX, E, "flags"},
> {"second_level_segment_size", "include segment size in segment filenames
> when use_localtime", 0, AV_OPT_TYPE_CONST, {.i64 =
> HLS_SECOND_LEVEL_SEGMENT_SIZE }, 0, UINT_MAX, E, "flags"},
> --
> 2.39.2 (Apple Git-143)
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Add init_program_date_time so start time can be specified
On Tue, Oct 17, 2023 at 7:09 PM wrote:
>
>
> On 17 Oct 2023, at 17:51, Dave Johansen wrote:
>
> > ---
> > doc/muxers.texi | 3 +++
> > libavformat/hlsenc.c | 7 ++-
> > 2 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/muxers.texi b/doc/muxers.texi
> > index f6071484ff..87c19a5cb9 100644
> > --- a/doc/muxers.texi
> > +++ b/doc/muxers.texi
> > @@ -1086,6 +1086,9 @@ seeking. This flag should be used with the
> @code{hls_time} option.
> > @item program_date_time
> > Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
> >
> > +@item init_program_date_time
> > +Time to start program date time at.
> > +
> > @item second_level_segment_index
> > Makes it possible to use segment indexes as %%d in hls_segment_filename
> expression
> > besides date/time values when strftime is on.
> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> > index 4ef84c05c1..474322cc21 100644
> > --- a/libavformat/hlsenc.c
> > +++ b/libavformat/hlsenc.c
> > @@ -28,6 +28,8 @@
> > #include
> > #endif
> >
> > +#include "float.h"
> > +
> > #include "libavutil/avassert.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/avstring.h"
> > @@ -212,6 +214,8 @@ typedef struct HLSContext {
> > int64_t recording_time;
> > int64_t max_seg_size; // every segment file max size
> >
> > +double init_program_date_time;
> > +
> > char *baseurl;
> > char *vtt_format_options_str;
> > char *subtitle_filename;
> > @@ -2867,7 +2871,7 @@ static int hls_init(AVFormatContext *s)
> > char *p = NULL;
> > int http_base_proto = ff_is_http_proto(s->url);
> > int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
> > -double initial_program_date_time = av_gettime() / 100.0;
> > +double initial_program_date_time = hls->init_program_date_time ?
> hls->init_program_date_time : av_gettime() / 100.0;
> >
> > if (hls->use_localtime) {
> > pattern = get_default_pattern_localtime_fmt(s);
> > @@ -3141,6 +3145,7 @@ static const AVOption options[] = {
> > {"split_by_time", "split the hls segment by time which user set by
> hls_time", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SPLIT_BY_TIME }, 0, UINT_MAX,
> E, "flags"},
> > {"append_list", "append the new segments into old hls segment
> list", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_APPEND_LIST }, 0, UINT_MAX, E,
> "flags"},
> > {"program_date_time", "add EXT-X-PROGRAM-DATE-TIME", 0,
> AV_OPT_TYPE_CONST, {.i64 = HLS_PROGRAM_DATE_TIME }, 0, UINT_MAX, E,
> "flags"},
> > +{"init_program_date_time", "Time to start program date time at",
> OFFSET(init_program_date_time), AV_OPT_TYPE_DOUBLE, {.dbl = 0 }, 0,
> DBL_MAX, E},
>
> This should probably not be mixed into the flags options list.
>
> It seems odd to have the user provide a double here instead of a ISO 8601
> datetime, which is what the spec requires / ends up in the playlist.
> If you do not want to handle the datetime string parsing, at least it
> would be good to give a hint what exactly the double value is expected to
> be here.
>
> However usability-wise I would prefer to accept a proper date/time here…
>
Is there an example of how to accept a string as the option and then do the
parsing that I could base the code on?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
