Re: [FFmpeg-devel] [PATCH] ffprobe: restore reporting error code for failed inputs
On Wed, 17 Aug 2022, Gyan Doshi wrote: On 2022-08-17 04:36 am, Stefano Sabatini wrote: On date Tuesday 2022-08-16 00:04:10 +0530, Gyan Doshi wrote: c11fb46731 led to a regression whereby the return code for missing input or input probe is overridden by writer close return code and hence not conveyed in the exit code. --- fftools/ffprobe.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Affects 5.1 so will need to be backported there. diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index ad633ccc44..8983dc28cc 100644 --- a/fftools/ffprobe.c +++ b/fftools/ffprobe.c @@ -4032,7 +4032,7 @@ int main(int argc, char **argv) WriterContext *wctx; char *buf; char *w_name = NULL, *w_args = NULL; -int ret, i; +int ret, input_ret, i; init_dynload(); @@ -4156,10 +4156,14 @@ int main(int argc, char **argv) show_error(wctx, ret); } +input_ret = ret; + writer_print_section_footer(wctx); ret = writer_close(&wctx); if (ret < 0) av_log(NULL, AV_LOG_ERROR, "Writing output failed: %s\n", av_err2str(ret)); + +ret = FFMIN(ret, input_ret); maybe we should give priority to input_ret in case they are both negative? return input_ret < 0 ? input_ret : ret; Scripts usually depend on exit code being 0 or something else. Also, error is logged for both input failure and writer_close failure, so it doesn't matter. Finally, input_ret is not initialized if writer_open fails, so we shouldn't be referencing it outside. I would do something like ret2 = writer_close(); ret = FFMIN(ret2, ret); But fine either way, please push any version you prefer, this has been broken for too long. Sorry about that. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavcodec/qsvenc: Add adaptive_i/b to hevc_qsv
Add adaptive_i/b feature to hevc_qsv. Adaptive_i allows changing of
frame type from P and B to I. Adaptive_b allows changing of frame type
frome B to P.
Signed-off-by: Wenbin Chen
---
doc/encoders.texi| 7 +++
libavcodec/qsvenc.c | 9 -
libavcodec/qsvenc_hevc.c | 2 ++
3 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 6d73f74196..fed798ff42 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -3543,6 +3543,13 @@ Setting this flag turns on or off LowDelayBRC feautre in
qsv plugin, which provi
more accurate bitrate control to minimize the variance of bitstream size frame
by frame. Value: -1-default 0-off 1-on
+@item @var{adaptive_i}
+This flag controls insertion of I frames by the QSV encoder. Turn ON this flag
+to allow changing of frame type from P and B to I.
+
+@item @var{adaptive_b}
+This flag controls changing of frame type from B to P.
+
@item @var{p_strategy}
Enable P-pyramid: 0-default 1-simple 2-pyramid(bf need to be set to 0).
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 4831640868..ca5e6f0b6e 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -816,11 +816,6 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
q->extco2.LookAheadDS = q->look_ahead_downsampling;
q->extco2.RepeatPPS = q->repeat_pps ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
-
-if (q->adaptive_i >= 0)
-q->extco2.AdaptiveI = q->adaptive_i ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
-if (q->adaptive_b >= 0)
-q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
}
if (avctx->codec_id == AV_CODEC_ID_H264 || avctx->codec_id ==
AV_CODEC_ID_HEVC) {
@@ -840,6 +835,10 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
if (q->b_strategy >= 0)
q->extco2.BRefType = q->b_strategy ? MFX_B_REF_PYRAMID :
MFX_B_REF_OFF;
+if (q->adaptive_i >= 0)
+q->extco2.AdaptiveI = q->adaptive_i ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
+if (q->adaptive_b >= 0)
+q->extco2.AdaptiveB = q->adaptive_b ? MFX_CODINGOPTION_ON :
MFX_CODINGOPTION_OFF;
if ((avctx->qmin >= 0 && avctx->qmax >= 0 && avctx->qmin >
avctx->qmax) ||
(q->max_qp_i >= 0 && q->min_qp_i >= 0 && q->min_qp_i >
q->max_qp_i) ||
(q->max_qp_p >= 0 && q->min_qp_p >= 0 && q->min_qp_p >
q->max_qp_p) ||
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index e11f5dec4a..19f028c078 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -233,6 +233,8 @@ static const AVOption options[] = {
QSV_OPTION_DBLK_IDC
QSV_OPTION_LOW_DELAY_BRC
QSV_OPTION_MAX_MIN_QP
+QSV_OPTION_ADAPTIVE_I
+QSV_OPTION_ADAPTIVE_B
{ "idr_interval", "Distance (in I-frames) between IDR frames",
OFFSET(qsv.idr_interval), AV_OPT_TYPE_INT, { .i64 = 0 }, -1, INT_MAX, VE,
"idr_interval" },
{ "begin_only", "Output an IDR-frame only at the beginning of the stream",
0, AV_OPT_TYPE_CONST, { .i64 = -1 }, 0, 0, VE, "idr_interval" },
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffprobe: restore reporting error code for failed inputs
On 2022-08-17 12:37 pm, Marton Balint wrote: On Wed, 17 Aug 2022, Gyan Doshi wrote: On 2022-08-17 04:36 am, Stefano Sabatini wrote: On date Tuesday 2022-08-16 00:04:10 +0530, Gyan Doshi wrote: c11fb46731 led to a regression whereby the return code for missing input or input probe is overridden by writer close return code and hence not conveyed in the exit code. --- fftools/ffprobe.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Affects 5.1 so will need to be backported there. diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index ad633ccc44..8983dc28cc 100644 --- a/fftools/ffprobe.c +++ b/fftools/ffprobe.c @@ -4032,7 +4032,7 @@ int main(int argc, char **argv) WriterContext *wctx; char *buf; char *w_name = NULL, *w_args = NULL; - int ret, i; + int ret, input_ret, i; init_dynload(); @@ -4156,10 +4156,14 @@ int main(int argc, char **argv) show_error(wctx, ret); } + input_ret = ret; + writer_print_section_footer(wctx); ret = writer_close(&wctx); if (ret < 0) av_log(NULL, AV_LOG_ERROR, "Writing output failed: %s\n", av_err2str(ret)); + + ret = FFMIN(ret, input_ret); maybe we should give priority to input_ret in case they are both negative? return input_ret < 0 ? input_ret : ret; Scripts usually depend on exit code being 0 or something else. Also, error is logged for both input failure and writer_close failure, so it doesn't matter. Finally, input_ret is not initialized if writer_open fails, so we shouldn't be referencing it outside. I would do something like ret2 = writer_close(); ret = FFMIN(ret2, ret); But fine either way, please push any version you prefer, this has been broken for too long. Sorry about that. The only diff is which return does the new variable store. I like my var name better :/ Will push in a couple of hours, 5.1 as well Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
Quoting Thilo Borgmann (2022-08-16 20:48:57) > Am 16.08.22 um 16:10 schrieb Anton Khirnov: > > Quoting Thilo Borgmann (2022-08-15 22:02:09) > >> $subject > >> > >> -Thilo > >> From fe2ff114cb004f897c7774753d9cf28298eba82d Mon Sep 17 00:00:00 2001 > >> From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= > >> Date: Mon, 15 Aug 2022 21:09:27 +0200 > >> Subject: [PATCH v2 2/4] ffmpeg: Add display_matrix option > >> > >> This enables overriding the rotation as well as horizontal/vertical > >> flip state of a specific video stream on the input side. > >> > >> Additionally, switch the singular test that was utilizing the rotation > >> metadata to instead override the input display rotation, thus leading > >> to the same result. > >> --- > > > > I still don't see how it's better to squash multiple options into a > > single option. > > > > It requires all this extra infrastructure and in the end it's less > > user-friendly, because user-understandable things like rotation or flips > > are now hidden under "display matrix". How many users would know what a > > display matrix is? > > FWIW I think Gyan's request to do this all in one option that effect one > thing (the display matrix) is valid. I don't. It may be one thing internally, but modeling user interfaces based on internal representation is a sinful malpractice. More importantly, I see no advantage from doing it - it only makes the option parsing more complicated. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavu/tx: implement aarch64 NEON SIMD
Quoting Paul B Mahol (2022-08-16 18:33:59) > On Tue, Aug 16, 2022 at 1:07 PM Anton Khirnov wrote: > > > Quoting Lynne (2022-08-14 06:31:50) > > > New - Total for len 131072 reps 4096 = 1.942836 s > > > Old - Segfaults > > > > ??? > > > > It is trivial. The fft code in lavc crashes in such case. So maybe that should be fixed? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option
Signed-off-by: Michael Riedl
---
libavfilter/vf_showinfo.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 2c8514fc80..1953f777c7 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -43,6 +43,7 @@
#include "libavutil/video_enc_params.h"
#include "libavutil/detection_bbox.h"
#include "libavutil/uuid.h"
+#include "libavutil/time.h"
#include "avfilter.h"
#include "internal.h"
@@ -51,6 +52,7 @@
typedef struct ShowInfoContext {
const AVClass *class;
int calculate_checksums;
+int print_wallclock;
} ShowInfoContext;
#define OFFSET(x) offsetof(ShowInfoContext, x)
@@ -58,6 +60,7 @@ typedef struct ShowInfoContext {
static const AVOption showinfo_options[] = {
{ "checksum", "calculate checksums", OFFSET(calculate_checksums),
AV_OPT_TYPE_BOOL, {.i64=1}, 0, 1, VF },
+{ "wallclock", "print wallclock", OFFSET(print_wallclock),
AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, VF },
{ NULL }
};
@@ -740,6 +743,14 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
sqrt((sum2[plane] -
sum[plane]*(double)sum[plane]/pixelcount[plane])/pixelcount[plane]));
av_log(ctx, AV_LOG_INFO, "\b]");
}
+
+if (s->print_wallclock) {
+av_log(ctx, AV_LOG_INFO,
+ " wallclock:%"PRId64" ",
+ av_gettime()
+);
+}
+
av_log(ctx, AV_LOG_INFO, "\n");
for (i = 0; i < frame->nb_side_data; i++) {
--
2.37.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option
Michael Riedl (12022-08-17): > Signed-off-by: Michael Riedl > --- > libavfilter/vf_showinfo.c | 11 +++ > 1 file changed, 11 insertions(+) What is the intended use case? It seems to me very ad-hoc. A fftools option to add a timestamp to each log line seems a more generic and cleaner approach. 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] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
---
libswscale/x86/swscale.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 32d441245d..881a4b7798 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -211,7 +211,7 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
filterSize, \
if(pixelsProcessed > 0) \
ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
pixelsProcessed + offset, dither, offset); \
if(remainder > 0){ \
- ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest - offset,
pixelsProcessed + remainder + offset, dither, offset); \
+ ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
offset, pixelsProcessed + remainder + offset, dither, offset); \
} \
return; \
}
--
2.37.1.595.g718a3a8f04-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
On 2022-08-17 01:48 pm, Anton Khirnov wrote: Quoting Thilo Borgmann (2022-08-16 20:48:57) Am 16.08.22 um 16:10 schrieb Anton Khirnov: Quoting Thilo Borgmann (2022-08-15 22:02:09) $subject -Thilo From fe2ff114cb004f897c7774753d9cf28298eba82d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= Date: Mon, 15 Aug 2022 21:09:27 +0200 Subject: [PATCH v2 2/4] ffmpeg: Add display_matrix option This enables overriding the rotation as well as horizontal/vertical flip state of a specific video stream on the input side. Additionally, switch the singular test that was utilizing the rotation metadata to instead override the input display rotation, thus leading to the same result. --- I still don't see how it's better to squash multiple options into a single option. It requires all this extra infrastructure and in the end it's less user-friendly, because user-understandable things like rotation or flips are now hidden under "display matrix". How many users would know what a display matrix is? FWIW I think Gyan's request to do this all in one option that effect one thing (the display matrix) is valid. I don't. It may be one thing internally, but modeling user interfaces based on internal representation is a sinful malpractice. More importantly, I see no advantage from doing it - it only makes the option parsing more complicated. It's not based on ffmpeg's 'internal representation'. All transform attributes are stored as a composite in one mathematical object. Evaluating the matrix values will need to look at all sources of contribution. So gathering and presenting all these attributes in a single option (+ docs) makes it clearer to the user at the cost of an initial learning curve. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/me_cmp: Remove now incorrect av_assert2()
Since d69d12a5b9236b9d2f1fd247ea452f84cdd1aaf9 these av_assert2()
(or more exactly, the ones in hadamard8_diff8x8_c() and
hadamard8_intra8x8_c()) are hit. So just remove all of these asserts.
(If the test were improved to know which functions expect h == 8
and which support any value, the asserts could be readded
at the appropriate places.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/me_cmp.c | 13 -
1 file changed, 13 deletions(-)
diff --git a/libavcodec/me_cmp.c b/libavcodec/me_cmp.c
index fa82ae54ae..4242fbc6e4 100644
--- a/libavcodec/me_cmp.c
+++ b/libavcodec/me_cmp.c
@@ -558,8 +558,6 @@ static int hadamard8_diff8x8_c(MpegEncContext *s, const
uint8_t *dst,
{
int i, temp[64], sum = 0;
-av_assert2(h == 8);
-
for (i = 0; i < 8; i++) {
// FIXME: try pointer walks
BUTTERFLY2(temp[8 * i + 0], temp[8 * i + 1],
@@ -610,8 +608,6 @@ static int hadamard8_intra8x8_c(MpegEncContext *s, const
uint8_t *src,
{
int i, temp[64], sum = 0;
-av_assert2(h == 8);
-
for (i = 0; i < 8; i++) {
// FIXME: try pointer walks
BUTTERFLY2(temp[8 * i + 0], temp[8 * i + 1],
@@ -662,8 +658,6 @@ static int dct_sad8x8_c(MpegEncContext *s, const uint8_t
*src1,
{
LOCAL_ALIGNED_16(int16_t, temp, [64]);
-av_assert2(h == 8);
-
s->pdsp.diff_pixels_unaligned(temp, src1, src2, stride);
s->fdsp.fdct(temp);
return s->mecc.sum_abs_dctelem(temp);
@@ -729,8 +723,6 @@ static int dct_max8x8_c(MpegEncContext *s, const uint8_t
*src1,
LOCAL_ALIGNED_16(int16_t, temp, [64]);
int sum = 0, i;
-av_assert2(h == 8);
-
s->pdsp.diff_pixels_unaligned(temp, src1, src2, stride);
s->fdsp.fdct(temp);
@@ -747,7 +739,6 @@ static int quant_psnr8x8_c(MpegEncContext *s, const uint8_t
*src1,
int16_t *const bak = temp + 64;
int sum = 0, i;
-av_assert2(h == 8);
s->mb_intra = 0;
s->pdsp.diff_pixels_unaligned(temp, src1, src2, stride);
@@ -776,8 +767,6 @@ static int rd8x8_c(MpegEncContext *s, const uint8_t *src1,
const uint8_t *src2,
const int esc_length = s->ac_esc_length;
uint8_t *length, *last_length;
-av_assert2(h == 8);
-
copy_block8(lsrc1, src1, 8, stride, 8);
copy_block8(lsrc2, src2, 8, stride, 8);
@@ -851,8 +840,6 @@ static int bit8x8_c(MpegEncContext *s, const uint8_t *src1,
const uint8_t *src2,
const int esc_length = s->ac_esc_length;
uint8_t *length, *last_length;
-av_assert2(h == 8);
-
s->pdsp.diff_pixels_unaligned(temp, src1, src2, stride);
s->block_last_index[0 /* FIXME */] =
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
Alan Kelly:
> ---
> libswscale/x86/swscale.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> index 32d441245d..881a4b7798 100644
> --- a/libswscale/x86/swscale.c
> +++ b/libswscale/x86/swscale.c
> @@ -211,7 +211,7 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
> filterSize, \
> if(pixelsProcessed > 0) \
> ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
> pixelsProcessed + offset, dither, offset); \
> if(remainder > 0){ \
> - ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> + ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> } \
> return; \
> }
What about the call to yuv2yuvX_mmx() in line 208 of this macro? Can it
not also be replaced by yuv2yuvX_mmxext()?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/me_cmp: Remove now incorrect av_assert2()
On Wed, 17 Aug 2022, Andreas Rheinhardt wrote: Since d69d12a5b9236b9d2f1fd247ea452f84cdd1aaf9 these av_assert2() (or more exactly, the ones in hadamard8_diff8x8_c() and hadamard8_intra8x8_c()) are hit. So just remove all of these asserts. (If the test were improved to know which functions expect h == 8 and which support any value, the asserts could be readded at the appropriate places.) Signed-off-by: Andreas Rheinhardt --- libavcodec/me_cmp.c | 13 - 1 file changed, 13 deletions(-) LGTM, thanks! // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
Gyan Doshi (12022-08-17):
> It's not based on ffmpeg's 'internal representation'. All transform
> attributes are stored as a composite in one mathematical object.
> Evaluating the matrix values will need to look at all sources of
> contribution. So gathering and presenting all these attributes in a single
> option (+ docs) makes it clearer to the user at the cost of an initial
> learning curve.
I concur a single option might be more convenient. Especially since our
options system does not take into account the order of options: the
interactions between multiple options would be rather hard to explain.
OTOH, I do not like a dictionary-based approach, for the same reason:
you have to explain the order of precedence of options, and how
contradicting ones interact.
Might I suggest to adopt the syntax of the transform attribute of SVG?
Or a subset of it with a stricter syntax.
https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform
It requires writing a specific parser, but one that can be done with
sscanf():
if (sscanf(cur, "translate(%d %d)%n", &dx, &dy, &off) >= 2 && off) {
translate_current_matrix(&mat, dx, dy);
cur += off;
}
Regards,
--
Nicolas George
--
“I dont see why” isnt an argument. Proposing better is.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option
On 17.08.2022 10:43, Nicolas George wrote: Michael Riedl (12022-08-17): Signed-off-by: Michael Riedl --- libavfilter/vf_showinfo.c | 11 +++ 1 file changed, 11 insertions(+) What is the intended use case? It seems to me very ad-hoc. A fftools option to add a timestamp to each log line seems a more generic and cleaner approach. This is a good idea, I will look into that. Regarding vf_showinfo, I am working on options to limit the output to certain frames (first N, last N, only I-frames). I think this will be useful, what do you think? Regards, -- Michael Riedl ___ 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] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
---
Call yuv2yuvX_mmxext on line 208 also.
libswscale/x86/swscale.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 32d441245d..e0f90d5c58 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -205,13 +205,13 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
filterSize, \
int remainder = (dstW % step); \
int pixelsProcessed = dstW - remainder; \
if(((uintptr_t)dest) & 15){ \
-yuv2yuvX_mmx(filter, filterSize, src, dest, dstW, dither, offset); \
+yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset); \
return; \
} \
if(pixelsProcessed > 0) \
ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
pixelsProcessed + offset, dither, offset); \
if(remainder > 0){ \
- ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest - offset,
pixelsProcessed + remainder + offset, dither, offset); \
+ ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
offset, pixelsProcessed + remainder + offset, dither, offset); \
} \
return; \
}
--
2.37.1.595.g718a3a8f04-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
Quoting Gyan Doshi (2022-08-17 10:50:43) > > > On 2022-08-17 01:48 pm, Anton Khirnov wrote: > > Quoting Thilo Borgmann (2022-08-16 20:48:57) > >> Am 16.08.22 um 16:10 schrieb Anton Khirnov: > >>> Quoting Thilo Borgmann (2022-08-15 22:02:09) > $subject > > -Thilo > From fe2ff114cb004f897c7774753d9cf28298eba82d Mon Sep 17 00:00:00 2001 > From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= > Date: Mon, 15 Aug 2022 21:09:27 +0200 > Subject: [PATCH v2 2/4] ffmpeg: Add display_matrix option > > This enables overriding the rotation as well as horizontal/vertical > flip state of a specific video stream on the input side. > > Additionally, switch the singular test that was utilizing the rotation > metadata to instead override the input display rotation, thus leading > to the same result. > --- > >>> I still don't see how it's better to squash multiple options into a > >>> single option. > >>> > >>> It requires all this extra infrastructure and in the end it's less > >>> user-friendly, because user-understandable things like rotation or flips > >>> are now hidden under "display matrix". How many users would know what a > >>> display matrix is? > >> FWIW I think Gyan's request to do this all in one option that effect one > >> thing (the display matrix) is valid. > > I don't. > > > > It may be one thing internally, but modeling user interfaces based on > > internal representation is a sinful malpractice. More importantly, I see > > no advantage from doing it - it only makes the option parsing more > > complicated. > > It's not based on ffmpeg's 'internal representation'. All transform > attributes are stored as a composite in one mathematical object. Keyword "stored". It is internal representation. Users should not care how it is stored, the entire point point of our project is to shield them from that as much as possible. > Evaluating the matrix values will need to look at all sources of > contribution. So gathering and presenting all these attributes in a single > option (+ docs) makes it clearer to the user at the cost of an initial > learning curve. Are you seriously expecting all users who want to mark a video as rotated or flipped to learn about display matrices? Nothing whatsoever about this is clearer. Just document in what order these options take effect (which has to be done anyway), and you're done. No need to inflict pointless complexity on people. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
Alan Kelly:
> ---
> Call yuv2yuvX_mmxext on line 208 also.
> libswscale/x86/swscale.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> index 32d441245d..e0f90d5c58 100644
> --- a/libswscale/x86/swscale.c
> +++ b/libswscale/x86/swscale.c
> @@ -205,13 +205,13 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
> filterSize, \
> int remainder = (dstW % step); \
> int pixelsProcessed = dstW - remainder; \
> if(((uintptr_t)dest) & 15){ \
> -yuv2yuvX_mmx(filter, filterSize, src, dest, dstW, dither, offset); \
> +yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither,
> offset); \
> return; \
> } \
> if(pixelsProcessed > 0) \
> ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
> pixelsProcessed + offset, dither, offset); \
> if(remainder > 0){ \
> - ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> + ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> } \
> return; \
> }
Does this not cause a warning because yuv2yuvX_mmx is now unused?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
---
Remove yuv2yuvX_mmx as it is no longer used.
libswscale/x86/swscale.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 32d441245d..89ef9f5d2b 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -205,20 +205,17 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
filterSize, \
int remainder = (dstW % step); \
int pixelsProcessed = dstW - remainder; \
if(((uintptr_t)dest) & 15){ \
-yuv2yuvX_mmx(filter, filterSize, src, dest, dstW, dither, offset); \
+yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither, offset); \
return; \
} \
if(pixelsProcessed > 0) \
ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
pixelsProcessed + offset, dither, offset); \
if(remainder > 0){ \
- ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest - offset,
pixelsProcessed + remainder + offset, dither, offset); \
+ ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
offset, pixelsProcessed + remainder + offset, dither, offset); \
} \
return; \
}
-#if HAVE_MMX_EXTERNAL
-YUV2YUVX_FUNC_MMX(mmx, 16)
-#endif
#if HAVE_MMXEXT_EXTERNAL
YUV2YUVX_FUNC_MMX(mmxext, 16)
#endif
--
2.37.1.595.g718a3a8f04-goog
___
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] avfilter/vf_showinfo: add wallclock option
Nicolas George: > Michael Riedl (12022-08-17): >> Signed-off-by: Michael Riedl >> --- >> libavfilter/vf_showinfo.c | 11 +++ >> 1 file changed, 11 insertions(+) > > What is the intended use case? It seems to me very ad-hoc. A fftools > option to add a timestamp to each log line seems a more generic and > cleaner approach. > Basically already exists: https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283434.html - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option
Andreas Rheinhardt (12022-08-17): > Basically already exists: > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/283434.html Lacks subsecond precision and timezone information, but a good start. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] sws: Replace call to yuv2yuvX_mmx by yuv2yuvX_mmxext
Alan Kelly:
> ---
> Remove yuv2yuvX_mmx as it is no longer used.
> libswscale/x86/swscale.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> index 32d441245d..89ef9f5d2b 100644
> --- a/libswscale/x86/swscale.c
> +++ b/libswscale/x86/swscale.c
> @@ -205,20 +205,17 @@ static void yuv2yuvX_ ##opt(const int16_t *filter, int
> filterSize, \
> int remainder = (dstW % step); \
> int pixelsProcessed = dstW - remainder; \
> if(((uintptr_t)dest) & 15){ \
> -yuv2yuvX_mmx(filter, filterSize, src, dest, dstW, dither, offset); \
> +yuv2yuvX_mmxext(filter, filterSize, src, dest, dstW, dither,
> offset); \
> return; \
> } \
> if(pixelsProcessed > 0) \
> ff_yuv2yuvX_ ##opt(filter, filterSize - 1, 0, dest - offset,
> pixelsProcessed + offset, dither, offset); \
> if(remainder > 0){ \
> - ff_yuv2yuvX_mmx(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> + ff_yuv2yuvX_mmxext(filter, filterSize - 1, pixelsProcessed, dest -
> offset, pixelsProcessed + remainder + offset, dither, offset); \
> } \
> return; \
> }
>
> -#if HAVE_MMX_EXTERNAL
> -YUV2YUVX_FUNC_MMX(mmx, 16)
> -#endif
> #if HAVE_MMXEXT_EXTERNAL
> YUV2YUVX_FUNC_MMX(mmxext, 16)
> #endif
Thanks. I'll apply this tonight unless someone else has objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
On 2022-08-17 02:35 pm, Anton Khirnov wrote: Quoting Gyan Doshi (2022-08-17 10:50:43) On 2022-08-17 01:48 pm, Anton Khirnov wrote: Quoting Thilo Borgmann (2022-08-16 20:48:57) Am 16.08.22 um 16:10 schrieb Anton Khirnov: Quoting Thilo Borgmann (2022-08-15 22:02:09) $subject -Thilo From fe2ff114cb004f897c7774753d9cf28298eba82d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= Date: Mon, 15 Aug 2022 21:09:27 +0200 Subject: [PATCH v2 2/4] ffmpeg: Add display_matrix option This enables overriding the rotation as well as horizontal/vertical flip state of a specific video stream on the input side. Additionally, switch the singular test that was utilizing the rotation metadata to instead override the input display rotation, thus leading to the same result. --- I still don't see how it's better to squash multiple options into a single option. It requires all this extra infrastructure and in the end it's less user-friendly, because user-understandable things like rotation or flips are now hidden under "display matrix". How many users would know what a display matrix is? FWIW I think Gyan's request to do this all in one option that effect one thing (the display matrix) is valid. I don't. It may be one thing internally, but modeling user interfaces based on internal representation is a sinful malpractice. More importantly, I see no advantage from doing it - it only makes the option parsing more complicated. It's not based on ffmpeg's 'internal representation'. All transform attributes are stored as a composite in one mathematical object. Keyword "stored". It is internal representation. Users should not care how it is stored, the entire point point of our project is to shield them from that as much as possible. Evaluating the matrix values will need to look at all sources of contribution. So gathering and presenting all these attributes in a single option (+ docs) makes it clearer to the user at the cost of an initial learning curve. Are you seriously expecting all users who want to mark a video as rotated or flipped to learn about display matrices? They don't need to know how to encode or decode the matrix if they don't want to. Only that it is the container. The difference is between -rotate:v:0 90 -hflip:v:0 1 -scale:v:0 2 and -display_matrix:v:0 rotate=90:hflip=1:scale=2 The latter syntax is all too familiar to users from AVFrame filters and BSFs. There's hardly any overhead here. They google or do Ctrl-F on ffmpeg.html for rotate, and they get to the display matrix option entry. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ffprobe: restore reporting error code for failed inputs
Pushed as d5544f6457ad06987311beda0e4b7c08bf52915c to master and 4e4cc6e56a899f6b4302e80dbcd6b4462f340905 to 5.1 On 2022-08-17 12:43 pm, Gyan Doshi wrote: On 2022-08-17 12:37 pm, Marton Balint wrote: On Wed, 17 Aug 2022, Gyan Doshi wrote: On 2022-08-17 04:36 am, Stefano Sabatini wrote: On date Tuesday 2022-08-16 00:04:10 +0530, Gyan Doshi wrote: c11fb46731 led to a regression whereby the return code for missing input or input probe is overridden by writer close return code and hence not conveyed in the exit code. --- fftools/ffprobe.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) Affects 5.1 so will need to be backported there. diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c index ad633ccc44..8983dc28cc 100644 --- a/fftools/ffprobe.c +++ b/fftools/ffprobe.c @@ -4032,7 +4032,7 @@ int main(int argc, char **argv) WriterContext *wctx; char *buf; char *w_name = NULL, *w_args = NULL; - int ret, i; + int ret, input_ret, i; init_dynload(); @@ -4156,10 +4156,14 @@ int main(int argc, char **argv) show_error(wctx, ret); } + input_ret = ret; + writer_print_section_footer(wctx); ret = writer_close(&wctx); if (ret < 0) av_log(NULL, AV_LOG_ERROR, "Writing output failed: %s\n", av_err2str(ret)); + + ret = FFMIN(ret, input_ret); maybe we should give priority to input_ret in case they are both negative? return input_ret < 0 ? input_ret : ret; Scripts usually depend on exit code being 0 or something else. Also, error is logged for both input failure and writer_close failure, so it doesn't matter. Finally, input_ret is not initialized if writer_open fails, so we shouldn't be referencing it outside. I would do something like ret2 = writer_close(); ret = FFMIN(ret2, ret); But fine either way, please push any version you prefer, this has been broken for too long. Sorry about that. The only diff is which return does the new variable store. I like my var name better :/ Will push in a couple of hours, 5.1 as well Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/4] ffmpeg: Add display_matrix option
Quoting Gyan Doshi (2022-08-17 12:53:11) > > > On 2022-08-17 02:35 pm, Anton Khirnov wrote: > > Quoting Gyan Doshi (2022-08-17 10:50:43) > >> > >> On 2022-08-17 01:48 pm, Anton Khirnov wrote: > >>> Quoting Thilo Borgmann (2022-08-16 20:48:57) > Am 16.08.22 um 16:10 schrieb Anton Khirnov: > > Quoting Thilo Borgmann (2022-08-15 22:02:09) > >> $subject > >> > >> -Thilo > >>From fe2ff114cb004f897c7774753d9cf28298eba82d Mon Sep 17 00:00:00 > >> 2001 > >> From: =?UTF-8?q?Jan=20Ekstr=C3=B6m?= > >> Date: Mon, 15 Aug 2022 21:09:27 +0200 > >> Subject: [PATCH v2 2/4] ffmpeg: Add display_matrix option > >> > >> This enables overriding the rotation as well as horizontal/vertical > >> flip state of a specific video stream on the input side. > >> > >> Additionally, switch the singular test that was utilizing the rotation > >> metadata to instead override the input display rotation, thus leading > >> to the same result. > >> --- > > I still don't see how it's better to squash multiple options into a > > single option. > > > > It requires all this extra infrastructure and in the end it's less > > user-friendly, because user-understandable things like rotation or flips > > are now hidden under "display matrix". How many users would know what a > > display matrix is? > FWIW I think Gyan's request to do this all in one option that effect one > thing (the display matrix) is valid. > >>> I don't. > >>> > >>> It may be one thing internally, but modeling user interfaces based on > >>> internal representation is a sinful malpractice. More importantly, I see > >>> no advantage from doing it - it only makes the option parsing more > >>> complicated. > >> It's not based on ffmpeg's 'internal representation'. All transform > >> attributes are stored as a composite in one mathematical object. > > Keyword "stored". It is internal representation. Users should not care > > how it is stored, the entire point point of our project is to shield > > them from that as much as possible. > > > >> Evaluating the matrix values will need to look at all sources of > >> contribution. So gathering and presenting all these attributes in a single > >> option (+ docs) makes it clearer to the user at the cost of an initial > >> learning curve. > > Are you seriously expecting all users who want to mark a video as > > rotated or flipped to learn about display matrices? > > They don't need to know how to encode or decode the matrix if they don't > want to. Only that it is the container. > > The difference is between > > -rotate:v:0 90 -hflip:v:0 1 -scale:v:0 2 > > and > > -display_matrix:v:0 rotate=90:hflip=1:scale=2 > > The latter syntax is all too familiar to users from AVFrame filters and > BSFs. The syntax similarity is misleading - filters are applied in the order you list them, while these options are always applied in fixed order. The analogous filters are also called rotate, [vf]flip, and scale - there is no display_matrix filter. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Keep data_partitioning in sync between threads
Fixes frame-threaded decoding of samples created by concatting a video with data partitioning and a video not using it. (Only the MPEG-4 decoder sets this, so it is synced in mpeg4_update_thread_context() despite being a MpegEncContext-field.) Signed-off-by: Andreas Rheinhardt --- libavcodec/mpeg4videodec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c index bfebc3806c..d89adf8d63 100644 --- a/libavcodec/mpeg4videodec.c +++ b/libavcodec/mpeg4videodec.c @@ -3534,6 +3534,7 @@ static int mpeg4_update_thread_context(AVCodecContext *dst, s->vol_sprite_usage = s1->vol_sprite_usage; s->sprite_brightness_change = s1->sprite_brightness_change; s->num_sprite_warping_points = s1->num_sprite_warping_points; +s->m.data_partitioning = s1->m.data_partitioning; s->rvlc = s1->rvlc; s->resync_marker = s1->resync_marker; s->t_frame = s1->t_frame; -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/8] avutil/mem: Handle fast allocations near UINT_MAX properly
Any update on this patchset? It's mostly fine as I recall /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] lavc/vaapi: Add support for remaining 10/12bit profiles
On Tue, Aug 16, 2022 at 12:55:38PM -0700, Philip Langdale wrote: > On Tue, 16 Aug 2022 12:52:52 -0700 > Philip Langdale wrote: > > > On Tue, 16 Aug 2022 19:29:24 +0200 > > Michael Niedermayer wrote: > > > > > > > CClibavutil/hwcontext_vaapi.o > > > > > libavutil/hwcontext_vaapi.c:103:9: error: > > > > > ‘VA_RT_FORMAT_YUV420_12’ undeclared here (not in a function); > > > > > did you mean ‘VA_RT_FORMAT_YUV420’? VA_RT_FORMAT_ ## rt, \ ^ > > > > > libavutil/hwcontext_vaapi.c:137:5: note: in expansion of macro > > > > > ‘MAP’ MAP(P016, YUV420_12, P016, 0), > > > > > ^~~ > > > > > ffbuild/common.mak:81: recipe for target > > > > > 'libavutil/hwcontext_vaapi.o' failed make: *** > > > > > [libavutil/hwcontext_vaapi.o] Error 1 > > > > > > > > > > > > > I guess there's probably a libva version dependency I need to > > > > guard for. What version do you have installed? > > > > > > ii libva-dev:amd64 > > >2.1.0-3 amd64 > > > > That's older than what I have, although I'd have thought it would be > > new enough. Regardless, I've included the appropriate #ifdef guard in > > the latest version of the patchset. > > > > Thanks, > > Ooops. I thought that said 2.10.0, not 2.1.0. 2.1.0 is ancient (2018) > but it turns out even 2.10.0 is too old. For the record it requires > 2.13.0. its not ancient its ubuntu LTS ;) or rather whats in it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter/vf_showinfo: add wallclock option
Michael Riedl (12022-08-17): > This is a good idea, I will look into that. Regarding vf_showinfo, I am > working on options to limit the output to certain frames (first N, last N, > only I-frames). I think this will be useful, what do you think? I strongly doubt it, but I will not object if the option is clean and unobtrusive enough. Please make sure the logic and implementation can easily be generalized to other filters. Regards, -- Nicolas George signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
tor 2022-08-11 klockan 19:35 +0200 skrev Timo Rothenpieler: > On 11.08.2022 19:21, Mark Gaiser wrote: > > > > Here's the conversation requesting this very feature: > > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293835.html > > I generally agree with the points brought up there. > But my conclusion very much is not "just put a somewhat random > default > into the code". > Even a list of defaults is not Okay. > We can't hardcode "magic servers". > > If it's not possible to make the protocol work without them, it > likely > shouldn't have been merged in the first place. > Why can't it access the files directly, but only via some magic http > gateway? > Why does it need special code in ffmpeg in the first place, if you > can > just access it via that http proxy-gateway anyway? I raised this very point several times when IPFS support was first suggested, and raised that ipfsgateway.c amounts to business logic that does not belong in lavf. I see now hat others in this thread, like Derek, agree with me on this, which is nice. IIRC I even suggested that users should solve this in bash, a suggestion that was shouted down as being "insecure". I also suggested we should actually implement ipfs or link to a library that implements it rather than shoving more string mangling crap into lavf. A default gateway didn't exist when I last looked at the patchset. Seems I wasn't vigilant enough. The correct place to solve this is at the OS level. There should be a fully fledged protocol handler in the OS that lavf can rely on, and neither lavf nor any other library should ever try to implement protocols themselvess. But that's more plan9-ish, so it will likely not happen in the Linux world any time soon. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/8] avutil/mem: Add av_fast_realloc_array()
Quoting Tomas Härdin (2022-07-21 23:23:25) > tis 2022-07-12 klockan 16:12 +0200 skrev Andreas Rheinhardt: > > > > Anton really dislikes the av_fast_* naming and instead wants this to > > be > > called av_realloc_array_reuse(). I don't care either way. Any more > > opinions on this (or on the patch itself)? > > That's going to cause some "impedance mismatch" given that the other > functions are still called fast rather than reuse, and changing that > would requite a major bump. One of my other points was that the existing "fast" functions use unsigned int rather than size_t, so that's another reason to replace them. Adding new functions and using them to replace all uses of the old ones in our codebase does not need a major bump. Actually removing the old ones does, but that can be done whenever. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/3] avcodec/mpegvideo: Allocate encoder-only tables in mpegvideo_enc.c
This commit moves the encoder-only allocations of the tables
owned solely by the main encoder context to mpegvideo_enc.c.
This avoids checks in mpegvideo.c for whether we are dealing
with an encoder; it also improves modularity (if encoders are
disabled, this code will no longer be included in the binary).
And it also avoids having to reset these pointers at the beginning
of ff_mpv_common_init() (in case the dst context is uninitialized,
ff_mpeg_update_thread_context() simply copies the src context
into dst which therefore may contain pointers not owned by it,
but this does not happen for encoders at all).
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo.c | 118 +++--
libavcodec/mpegvideo_enc.c | 67 -
2 files changed, 72 insertions(+), 113 deletions(-)
diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c
index 1190f29954..86fe5e4022 100644
--- a/libavcodec/mpegvideo.c
+++ b/libavcodec/mpegvideo.c
@@ -566,61 +566,13 @@ int ff_mpv_init_context_frame(MpegEncContext *s)
s->mb_index2xy[s->mb_height * s->mb_width] = (s->mb_height - 1) *
s->mb_stride + s->mb_width; // FIXME really needed?
-if (s->encoding) {
-/* Allocate MV tables */
-if (!FF_ALLOCZ_TYPED_ARRAY(s->p_mv_table_base,
mv_table_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->b_forw_mv_table_base,
mv_table_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->b_back_mv_table_base,
mv_table_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->b_bidir_forw_mv_table_base,
mv_table_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->b_bidir_back_mv_table_base,
mv_table_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->b_direct_mv_table_base,
mv_table_size))
-return AVERROR(ENOMEM);
-s->p_mv_table= s->p_mv_table_base + s->mb_stride + 1;
-s->b_forw_mv_table = s->b_forw_mv_table_base + s->mb_stride + 1;
-s->b_back_mv_table = s->b_back_mv_table_base + s->mb_stride + 1;
-s->b_bidir_forw_mv_table = s->b_bidir_forw_mv_table_base +
s->mb_stride + 1;
-s->b_bidir_back_mv_table = s->b_bidir_back_mv_table_base +
s->mb_stride + 1;
-s->b_direct_mv_table = s->b_direct_mv_table_base + s->mb_stride +
1;
-
-/* Allocate MB type table */
-if (!FF_ALLOCZ_TYPED_ARRAY(s->mb_type, mb_array_size) ||
-!FF_ALLOCZ_TYPED_ARRAY(s->lambda_table, mb_array_size) ||
-!FF_ALLOC_TYPED_ARRAY (s->cplx_tab, mb_array_size) ||
-!FF_ALLOC_TYPED_ARRAY (s->bits_tab, mb_array_size))
-return AVERROR(ENOMEM);
-
-#define ALLOCZ_ARRAYS(p, mult, numb) ((p) = av_calloc(numb, mult *
sizeof(*(p
-if (s->codec_id == AV_CODEC_ID_MPEG4 ||
-(s->avctx->flags & AV_CODEC_FLAG_INTERLACED_ME)) {
-int16_t (*tmp1)[2];
-uint8_t *tmp2;
-if (!(tmp1 = ALLOCZ_ARRAYS(s->b_field_mv_table_base, 8,
mv_table_size)) ||
-!(tmp2 = ALLOCZ_ARRAYS(s->b_field_select_table[0][0], 2 * 4,
mv_table_size)) ||
-!ALLOCZ_ARRAYS(s->p_field_select_table[0], 2 * 2,
mv_table_size))
-return AVERROR(ENOMEM);
-
-s->p_field_select_table[1] = s->p_field_select_table[0] + 2 *
mv_table_size;
-tmp1 += s->mb_stride + 1;
-
-for (int i = 0; i < 2; i++) {
-for (int j = 0; j < 2; j++) {
-for (int k = 0; k < 2; k++) {
-s->b_field_mv_table[i][j][k] = tmp1;
-tmp1 += mv_table_size;
-}
-s->b_field_select_table[i][j] = tmp2;
-tmp2 += 2 * mv_table_size;
-}
-}
-}
-}
-
if (s->codec_id == AV_CODEC_ID_MPEG4 ||
(s->avctx->flags & AV_CODEC_FLAG_INTERLACED_ME)) {
-int16_t (*tmp)[2];
/* interlaced direct mode decoding tables */
-if (!(tmp = ALLOCZ_ARRAYS(s->p_field_mv_table_base, 4, mv_table_size)))
+int16_t (*tmp)[2] = av_calloc(mv_table_size, 4 * sizeof(*tmp));
+if (!tmp)
return AVERROR(ENOMEM);
+s->p_field_mv_table_base = tmp;
tmp += s->mb_stride + 1;
for (int i = 0; i < 2; i++) {
for (int j = 0; j < 2; j++) {
@@ -663,8 +615,6 @@ int ff_mpv_init_context_frame(MpegEncContext *s)
static void clear_context(MpegEncContext *s)
{
-int i, j, k;
-
memset(&s->next_picture, 0, sizeof(s->next_picture));
memset(&s->last_picture, 0, sizeof(s->last_picture));
memset(&s->current_picture, 0, sizeof(s->current_picture));
@@ -693,31 +643,10 @@ static void clear_context(MpegEncContext *s)
s->bitstream_buffer = NULL;
s->allocated_bitstream_buffer_size = 0;
s->picture = NULL;
-s->mb_type = NULL;
-s->p_mv_table_base = NULL;
-s->b_forw_mv_table_base = NULL;
-s->b_back_mv_table_base = NULL;
-s->b_bid
[FFmpeg-devel] [PATCH 0/1] doc: fix binary values of SI prefixes
Simple SI/binary fixes. Chema Gonzalez (1): doc: fix binary values of SI prefixes doc/utils.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) -- 2.37.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 1/1] doc: fix binary values of SI prefixes
--- doc/utils.texi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/utils.texi b/doc/utils.texi index 232a0608b3..627b55d154 100644 --- a/doc/utils.texi +++ b/doc/utils.texi @@ -1073,13 +1073,13 @@ indication of the corresponding powers of 10 and of 2. @item T 10^12 / 2^40 @item P -10^15 / 2^40 +10^15 / 2^50 @item E -10^18 / 2^50 +10^18 / 2^60 @item Z -10^21 / 2^60 +10^21 / 2^70 @item Y -10^24 / 2^70 +10^24 / 2^80 @end table @c man end EXPRESSION EVALUATION -- 2.37.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] API enhancements / broken promises
Hi On Mon, Aug 15, 2022 at 06:47:34PM +0200, Nicolas George wrote: > Hi. > > Over the years, I have promised quite a few enhancement to FFmpeg's API, > some of them connecting to user interface: stored error messages instead > of just logging, universal serialization of objects into various formats > (JSON, XML, etc.), a way to exfiltrate data from filters and other > components, better options parsing avoiding multiple levels of escaping, > asynchronous interface for protocols and later formats, avoiding global > state including a more reliable control of allowed components, and I > might be forgetting a few of them. > > I will not be able to make good on these promises, mostly for no fault > of mine. > > I have detailed plans on how to achieve any of these goals; I would not > have proposed otherwise. I can explain them if somebody is interested. > > A lot of these projects require a good string API. Unfortunately, my > proposal for that is being blocked by a member of the tech committee > who, by their own admission, almost never deals with strings and never > used BPrint, and whose arguments amount to “I am not convinced we need > it”, and the others members of the committee do not care enough to > override them. As i said elsewhere i think replacing BPrint by AVWriter is a good idea. and also that the TC does to the best of my knowledge have no power in this case. We first need some patch and disagreement the TC could vote on. ATM there is no public disagreement on a patch i think But i didnt hit reply to repeat that. Rather i wanted to comment on XML and JSON and FFmpeg. I saw on IRC this (authors removed because their names are not important here, iam really replying to the statments not the people) A> but I, IMVHO, dont think this project should get a XML parser B> "nice and limited" XML parser sounds like all sorts of "fun" C> Yeah, xml/json/... parser in ffmpeg is just... no Whats the purpose of FFmpeg ? "A complete, cross-platform solution to record, convert and stream audio and video." first actually i think that should be chnaged to something like this: "A complete, cross-platform solution to your multmedia needs" Because there are subtitles and many other things we do care about that this misses Now to achieve this do we need xml and json ? grep tells me we have 500 matches (not counting docs) for xml and almost 100 for json Also for streaming and some cases filtering being able to serialize objects would be useful. xml and json seem better choices than some ad-hoc format So i would awnser the question do we need XML and JSON, with yes we live in a world that uses XML and JSON so if we give the option to use it too that makes it easier for others to interact. now do we need our own implementation of it ? I dont know but we have in almost all cases favored our native implementations when someone wrote one. And libxml2 has had so many security issues that i think we should at least consider replacing it. The 2nd thing that comes to mind with "purpose of FFmpeg" is FF stands for "Fast Forward". To move fast forward we should not lose developers because of rather minor disagreements. IMO if Nicolas wants to write and maintain AVWriter and a simple xml parser (which i presume has the goal to parse the XML we would generate for serialization and in other places). I really think telling Nicolas "no" is a unwise choice. But if someone is against very basic xml or json parsers please speak up now and here because its still better to say "no" now than after nicolas did the work. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I know you won't believe me, but the highest form of Human Excellence is to question oneself and others. -- Socrates 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] checkasm: sw_scale: Fix the difference printing for approximate functions
Don't stop directly at the first differing pixel, but find the
one that differs by more than the expected accuracy.
Also print the failing value in check_yuv2yuvX.
Signed-off-by: Martin Storsjö
---
tests/checkasm/sw_scale.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c
index cbe4460a99..d72506ed86 100644
--- a/tests/checkasm/sw_scale.c
+++ b/tests/checkasm/sw_scale.c
@@ -77,10 +77,10 @@ static void print_data(uint8_t *p, size_t len, size_t
offset)
}
}
-static size_t show_differences(uint8_t *a, uint8_t *b, size_t len)
+static size_t show_differences(uint8_t *a, uint8_t *b, size_t len, int
accuracy)
{
for (size_t i = 0; i < len; i++) {
-if (a[i] != b[i]) {
+if (abs(a[i] - b[i]) > accuracy) {
size_t offset_of_mismatch = i;
size_t offset;
if (i >= 8) i-=8;
@@ -141,7 +141,7 @@ static void check_yuv2yuv1(int accurate)
if (cmp_off_by_n(dst0, dst1, dstW * sizeof(dst0[0]), accurate
? 0 : 2)) {
fail();
printf("failed: yuv2yuv1_%d_%di_%s\n", offset, dstW,
accurate_str);
-fail_offset = show_differences(dst0, dst1,
LARGEST_INPUT_SIZE * sizeof(dst0[0]));
+fail_offset = show_differences(dst0, dst1,
LARGEST_INPUT_SIZE * sizeof(dst0[0]), accurate ? 0 : 2);
printf("failing values: src: 0x%04x dither: 0x%02x dst-c:
%02x dst-asm: %02x\n",
(int) src_pixels[fail_offset],
(int) dither[(fail_offset + fail_offset) & 7],
@@ -169,6 +169,7 @@ static void check_yuv2yuvX(int accurate)
static const int input_sizes[] = {8, 24, 128, 144, 256, 512};
const int INPUT_SIZES = sizeof(input_sizes)/sizeof(input_sizes[0]);
const char *accurate_str = (accurate) ? "accurate" : "approximate";
+size_t fail_offset;
declare_func_emms(AV_CPU_FLAG_MMX, void, const int16_t *filter,
int filterSize, const int16_t **src, uint8_t *dest,
@@ -224,7 +225,12 @@ static void check_yuv2yuvX(int accurate)
if (cmp_off_by_n(dst0, dst1, LARGEST_INPUT_SIZE *
sizeof(dst0[0]), accurate ? 0 : 2)) {
fail();
printf("failed: yuv2yuvX_%d_%d_%d_%s\n",
filter_sizes[fsi], osi, dstW, accurate_str);
-show_differences(dst0, dst1, LARGEST_INPUT_SIZE *
sizeof(dst0[0]));
+fail_offset = show_differences(dst0, dst1,
LARGEST_INPUT_SIZE * sizeof(dst0[0]), accurate ? 0 : 2);
+printf("failing values: src: 0x%04x dither: 0x%02x
dst-c: %02x dst-asm: %02x\n",
+(int) src_pixels[fail_offset],
+(int) dither[(fail_offset + osi) & 7],
+(int) dst0[fail_offset],
+(int) dst1[fail_offset]);
}
if(dstW == LARGEST_INPUT_SIZE)
bench_new((const int16_t*)vFilterData,
filter_sizes[fsi], src, dst1, dstW - osi, dither, osi);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] checkasm: sw_scale: Reduce range of test data in the yuv2yuvX test to get closer to real data
This avoids overflows on some inputs in the x86 case, where the assembly version would clip/overflow differently from the C reference function. This doesn't seem to be a real issue with actual input data, but only with the previous fully random input data. This also makes the test produce a bit more realistic output pixel values, instead of having essentially all pixels clipped to either 0 or 255. Signed-off-by: Martin Storsjö --- tests/checkasm/sw_scale.c | 8 1 file changed, 8 insertions(+) diff --git a/tests/checkasm/sw_scale.c b/tests/checkasm/sw_scale.c index d72506ed86..89403da317 100644 --- a/tests/checkasm/sw_scale.c +++ b/tests/checkasm/sw_scale.c @@ -187,8 +187,16 @@ static void check_yuv2yuvX(int accurate) } *vFilterData; uint8_t d_val = rnd(); memset(dither, d_val, LARGEST_INPUT_SIZE); + randomize_buffers((uint8_t*)src_pixels, LARGEST_FILTER * LARGEST_INPUT_SIZE * sizeof(int16_t)); randomize_buffers((uint8_t*)filter_coeff, LARGEST_FILTER * sizeof(int16_t)); +// Limit the range of the filter coefficients and intermediate +// pixel values, to avoid risk of clipping filter intermediates on x86. +for (i = 0; i < LARGEST_FILTER; i++) +filter_coeff[i] >>= 2; +for (i = 0; i < LARGEST_FILTER * LARGEST_INPUT_SIZE; i++) +src_pixels[i] >>= 2; + ctx = sws_alloc_context(); if (accurate) ctx->flags |= SWS_ACCURATE_RND; -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] API enhancements / broken promises
Hi. Michael Niedermayer (12022-08-17): > As i said elsewhere i think replacing BPrint by AVWriter is a good idea. > and also that the TC does to the best of my knowledge have no power in > this case. We first need some patch and disagreement the TC could vote > on. ATM there is no public disagreement on a patch i think > > But i didnt hit reply to repeat that. Thank you and thank Stefano for your encouraging replies. With them and the comments I had in private and/or earlier, I am beginning to feel confident I can override the argument-less objection. Note that I am not asking for a blank check to push anything I want. I will of course submit the code for review and adhere to the technical comments made to it. And I want to insist, not just for me: this is a mechanism we need. Right now, the only way to know if a change will be accepted is to submit a patch series in its almost final shape. For something ambitious, that can mean a lot of work, and if the patches are eventually rejected, that work goes to waste. The possibility that it happens is discouraging. And with that discouragement, we only get low-hanging fruits, changes that are sure to be accepted. Or we get intimidation: submit a 100+ patch series, present the project with a fait accopli, and count on the fact that nobody will dare object in the face of the sheer amount of work, even if the proposal is flawed at its core and would need a complete rewrite. The lack of a procedure to engage in something ambitious without the risk of outright rejection is limiting the progress of FFmpeg, and it is sad. Maybe this simple idea would be enough, if people like it: doc/plans.md containing more-or-less detailed plans of ambitious plans. Patches to doc/plans.md are reviewed on the mailing list like any other patches. But once a plan is accepted, patches that implement it cannot be objected on principle by naysayers and bikeshedders, only on technical matters. I will try to propose a small patch for that, to get the conversation going. > Rather i wanted to comment on > XML and JSON and FFmpeg. Thanks. > I saw on IRC this (authors removed because their names are not important here, > iam really replying to the statments not the people) > A> but I, IMVHO, dont think this project should get a XML parser > B> "nice and limited" XML parser sounds like all sorts of "fun" > C> Yeah, xml/json/... parser in ffmpeg is just... no > > Whats the purpose of FFmpeg ? > "A complete, cross-platform solution to record, convert and stream audio and > video." > first actually i think that should be chnaged to something like this: > "A complete, cross-platform solution to your multmedia needs" > Because there are subtitles and many other things we do care about that this > misses > > Now to achieve this do we need xml and json ? > grep tells me we have 500 matches (not counting docs) for xml and almost 100 > for json > Also for streaming and some cases filtering being able to serialize objects > would be useful. xml and json seem better choices than some ad-hoc format > So i would awnser the question do we need XML and JSON, with yes we live > in a world that uses XML and JSON so if we give the option to use it too > that makes it easier for others to interact. > > now do we need our own implementation of it ? I dont know but we have > in almost all cases favored our native implementations when someone wrote > one. And libxml2 has had so many security issues that i think we should > at least consider replacing it. Replacing our use of libxml2 was my reason for starting to think and then write a XML parser, for exactly the reasons we describe, plus the fact that libxml2 is not a system library. We need XML for at least MPEG-DASH and IMF, which are unambiguously part of FFmpeg's purpose. And the objective of the "limited" parser would be to be able to digest DASH manifests found in the wild. > The 2nd thing that comes to mind with "purpose of FFmpeg" is FF stands for > "Fast Forward". To move fast forward we should not lose developers because of > rather minor disagreements. > IMO if Nicolas wants to write and maintain AVWriter and a simple xml parser > (which i presume has the goal to parse the XML we would generate for > serialization and in other places). I really think telling Nicolas "no" is > a unwise choice. But if someone is against very basic xml or json parsers > please speak up now and here because its still better to say "no" now than > after nicolas did the work. Thanks again. It is exactly my concern. If we collectively decide we do not want some project, I can work on something else. But the uncertainty is killing my motivation. 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
Re: [FFmpeg-devel] [PATCH 2/2] checkasm: sw_scale: Reduce range of test data in the yuv2yuvX test to get closer to real data
Hi, On Wed, Aug 17, 2022 at 4:32 PM Martin Storsjö wrote: > This avoids overflows on some inputs in the x86 case, where the > assembly version would clip/overflow differently from the > C reference function. > > This doesn't seem to be a real issue with actual input data, but > only with the previous fully random input data. > I'm a bit scared of this change... If we can trigger overflows with specific pixel patterns, doesn't that make FFmpeg input-data exploitable? Think of how that would go with corporate users with user-provided input data. Ronald ___ 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] doc/plans: add a file to list approved projects
This file makes it easier to engage in ambitious and/or long-term projects for enhancing FFmpeg by removing earlier the uncertainty of acceptance on principle. Signed-off-by: Nicolas George --- doc/plans.md | 6 ++ 1 file changed, 6 insertions(+) create mode 100644 doc/plans.md Reference to discussion: https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300193.html diff --git a/doc/plans.md b/doc/plans.md new file mode 100644 index 00..0d7336e8b4 --- /dev/null +++ b/doc/plans.md @@ -0,0 +1,6 @@ +# Plans for future developments + +Projects listed below have been approved by the FFmpeg developers community, +and their author(s) can invest time and effort implementing them. The +resulting patches will be subject to technical review like any other +patches, but they can no longer be rejected on principle. -- 2.35.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] doc/plans: add AVWriter
Signed-off-by: Nicolas George --- doc/plans.md | 38 ++ 1 file changed, 38 insertions(+) diff --git a/doc/plans.md b/doc/plans.md index 0d7336e8b4..d96328aabc 100644 --- a/doc/plans.md +++ b/doc/plans.md @@ -4,3 +4,41 @@ Projects listed below have been approved by the FFmpeg developers community, and their author(s) can invest time and effort implementing them. The resulting patches will be subject to technical review like any other patches, but they can no longer be rejected on principle. + +## AVWriter: a unified API for building and returning strings + +**Author:** Nicolas George + +An API that can be used everywhere a function needs to return a string, or +really an arbitrary buffer of bytes, and everywhere code needs to build a +string from parts. It needs to be fast and lightweight enough to be used in +tight loops, like once per frame, without limiting the size of the returned +string when needed. It should make checking for overflows and possible +memory allocation errors simple. It should easily be compatible with other +uses of strings, especially standard C buffers. + +AVWriter is an enhancement on the AVBPrint API; AVBPrint already achieves +some of these objectives but not all. + +Like other FFmpeg components, AVWriter is designed as a limited +object-oriented virtual class / interface with multiple implementations. To +let applications define their own writers and allocate structures on the +stack or as part of their data, structures contain their own size and the +code only accesses fields that exist. + +Some functions are specific to a particular implementation of AVWriter; for +example getting a mallocated buffer from a dynamic AVWriter. It is the +responsibility of the caller to use the right type, which will usually be +enforced by an assert. + +**Future plans where AVWriter will help:** + +A universal API to return the string associated with an elementary type +(pixel format, channel layout, etc.) and to serialize complex types, +especially side data. + +A system to store error messages in contexts instead of logging them, to +make it easier for applications, especially GUI, to display them cleanly. + +An extension to `avwriter_printf()` to use any serializable object directly +from the format string. -- 2.35.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/7] avcodec/h263dec: Remove redundant code to set cur_pic_ptr
Michael Niedermayer: > On Mon, Aug 15, 2022 at 01:49:24PM +0200, Andreas Rheinhardt wrote: >> It is done later in ff_mpv_frame_start() (and nobody uses >> current_picture_ptr between setting it in ff_mpv_frame_start()). >> >> (The reason the vsynth*-h263-obmc code changes is because >> the call to ff_find_unused_picture() now happens after the older >> pictures have been unreferenced in ff_mpv_frame_start(), >> so that their slots in the picture array can be immediately >> reused; the obmc code is somehow buggy and changes its output >> depending on the earlier contents of the motion_val buffer.) >> >> Signed-off-by: Andreas Rheinhardt >> --- > >> I'd like to take this opportunity to once again ask anyone familiar >> with H.263 to take a look at this OBMC issue. > > Iam too busy ATM :( i might look at some point but its not very high > on my todo as it works :) security & release is more important > If you (and no one else) don't object, I'll apply this tomorrow. > but i can say this breaks fate as it is: > > --- ./tests/ref/vsynth/vsynth1-h263-obmc 2022-08-16 00:19:00.345967181 > +0200 > +++ tests/data/fate/vsynth1-h263-obmc 2022-08-16 00:19:05.262017999 +0200 > @@ -1,4 +1,4 @@ > 7dec64380f375e5118b66f3b1e24 *tests/data/fate/vsynth1-h263-obmc.avi > 657320 tests/data/fate/vsynth1-h263-obmc.avi > -f5048b5f0c98833a1d11f8034fb1827f > *tests/data/fate/vsynth1-h263-obmc.out.rawvideo > -stddev:8.12 PSNR: 29.93 MAXDIFF: 113 bytes: 7603200/ 7603200 > +2a69f6b37378aa34418dfd04ec98c1c8 > *tests/data/fate/vsynth1-h263-obmc.out.rawvideo > +stddev:8.38 PSNR: 29.66 MAXDIFF: 116 bytes: 7603200/ 7603200 > Test vsynth1-h263-obmc failed. Look at tests/data/fate/vsynth1-h263-obmc.err > for details. > tests/Makefile:304: recipe for target 'fate-vsynth1-h263-obmc' failed > make: *** [fate-vsynth1-h263-obmc] Error 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] avformat/avidec: Prevent entity expansion attacks
Fixes: Timeout
Fixes no testcase, this is the same idea as similar attacks against XML parsers
Signed-off-by: Michael Niedermayer
---
libavformat/avidec.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 937d9e6ffb..910a4e8792 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -82,6 +82,8 @@ typedef struct AVIContext {
int stream_index;
DVDemuxContext *dv_demux;
int odml_depth;
+int64_t odml_read;
+int64_t odml_max_pos;
int use_odml;
#define MAX_ODML_DEPTH 1000
int64_t dts_max;
@@ -200,7 +202,7 @@ static int read_odml_index(AVFormatContext *s, int64_t
frame_num)
st = s->streams[stream_id];
ast = st->priv_data;
-if (index_sub_type)
+if (index_sub_type || entries_in_use < 0)
return AVERROR_INVALIDDATA;
avio_rl32(pb);
@@ -221,11 +223,18 @@ static int read_odml_index(AVFormatContext *s, int64_t
frame_num)
}
for (i = 0; i < entries_in_use; i++) {
+avi->odml_max_pos = FFMAX(avi->odml_max_pos, avio_tell(pb));
+
+// If we read more than there are bytes then we must have been reading
something twice
+if (avi->odml_read > avi->odml_max_pos)
+return AVERROR_INVALIDDATA;
+
if (index_type) {
int64_t pos = avio_rl32(pb) + base - 8;
int len = avio_rl32(pb);
int key = len >= 0;
len &= 0x7FFF;
+avi->odml_read += 8;
av_log(s, AV_LOG_TRACE, "pos:%"PRId64", len:%X\n", pos, len);
@@ -244,6 +253,7 @@ static int read_odml_index(AVFormatContext *s, int64_t
frame_num)
int64_t offset, pos;
int duration;
int ret;
+avi->odml_read += 16;
offset = avio_rl64(pb);
avio_rl32(pb); /* size */
--
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 v2 1/3] lavc/decode: Warp get_hw_config function
From: Linjie Fu
Wrap the procedure of getting the hardware config from a pixel format
into a function.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/decode.c | 31 +++
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 75373989c6..3b69426c09 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1156,6 +1156,24 @@ static void hwaccel_uninit(AVCodecContext *avctx)
av_buffer_unref(&avctx->hw_frames_ctx);
}
+static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext *avctx,
enum AVPixelFormat fmt)
+{
+const AVCodecHWConfigInternal *hw_config;
+
+if (!ffcodec(avctx->codec)->hw_configs)
+return NULL;
+
+for (int i = 0;; i++) {
+hw_config = ffcodec(avctx->codec)->hw_configs[i];
+if (!hw_config)
+return NULL;
+if (hw_config->public.pix_fmt == fmt)
+return hw_config;
+}
+
+return NULL;
+}
+
int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
{
const AVPixFmtDescriptor *desc;
@@ -1213,18 +1231,7 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
break;
}
-if (ffcodec(avctx->codec)->hw_configs) {
-for (i = 0;; i++) {
-hw_config = ffcodec(avctx->codec)->hw_configs[i];
-if (!hw_config)
-break;
-if (hw_config->public.pix_fmt == user_choice)
-break;
-}
-} else {
-hw_config = NULL;
-}
-
+hw_config = get_hw_config(avctx, user_choice);
if (!hw_config) {
// No config available, so no extra setup required.
ret = user_choice;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/3] lavc/decode: Add internal surface re-allocate method for hwaccel
From: Linjie Fu
Add HWACCEL_CAP_INTERNAL_ALLOC flag to indicate hwaccels are able to
re-allocate surface internally through ff_decode_get_hw_frames_ctx.
So that hwaccels don't need to reinitialize all hw configs when decode
parameters change.
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/decode.c | 36
libavcodec/hwconfig.h | 1 +
2 files changed, 37 insertions(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 3b69426c09..6a22627036 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1174,6 +1174,33 @@ static const AVCodecHWConfigInternal
*get_hw_config(AVCodecContext *avctx, enum
return NULL;
}
+static int hwaccel_realloc_surface(AVCodecContext *avctx)
+{
+const AVCodecHWConfigInternal *hw_config;
+int ret;
+
+if (avctx->hw_frames_ctx)
+av_buffer_unref(&avctx->hw_frames_ctx);
+
+hw_config = get_hw_config(avctx, avctx->pix_fmt);
+if (!hw_config)
+return AV_PIX_FMT_NONE;
+
+if (avctx->hw_device_ctx &&
+hw_config->public.methods & AV_CODEC_HW_CONFIG_METHOD_HW_DEVICE_CTX) {
+const AVHWDeviceContext *device_ctx =
+(AVHWDeviceContext*)avctx->hw_device_ctx->data;
+ret = ff_decode_get_hw_frames_ctx(avctx, device_ctx->type);
+if (ret < 0) {
+av_log(avctx, AV_LOG_WARNING, "Failed to re-allocate hwaccel
surface internally.\n");
+return AV_PIX_FMT_NONE;
+}
+} else
+return AV_PIX_FMT_NONE;
+
+return hw_config->public.pix_fmt;
+}
+
int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt)
{
const AVPixFmtDescriptor *desc;
@@ -1200,6 +1227,15 @@ int ff_get_format(AVCodecContext *avctx, const enum
AVPixelFormat *fmt)
return AV_PIX_FMT_NONE;
for (;;) {
+if (avctx->internal->hwaccel_priv_data &&
+avctx->hwaccel->caps_internal & HWACCEL_CAP_INTERNAL_ALLOC) {
+err = hwaccel_realloc_surface(avctx);
+if (err < 0)
+av_log(avctx, AV_LOG_WARNING, "Try to re-initialize all.\n");
+else
+return err;
+}
+
// Remove the previous hwaccel, if there was one.
hwaccel_uninit(avctx);
diff --git a/libavcodec/hwconfig.h b/libavcodec/hwconfig.h
index 721424912c..7405c66c07 100644
--- a/libavcodec/hwconfig.h
+++ b/libavcodec/hwconfig.h
@@ -24,6 +24,7 @@
#define HWACCEL_CAP_ASYNC_SAFE (1 << 0)
+#define HWACCEL_CAP_INTERNAL_ALLOC (1 << 1)
typedef struct AVCodecHWConfigInternal {
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/3] lavc/vaapi_vp9: add surface internal re-allocation capability
From: Linjie Fu
Signed-off-by: Linjie Fu
Signed-off-by: Fei Wang
---
libavcodec/vaapi_vp9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_vp9.c b/libavcodec/vaapi_vp9.c
index 776382f683..fc6ff0a0f2 100644
--- a/libavcodec/vaapi_vp9.c
+++ b/libavcodec/vaapi_vp9.c
@@ -181,5 +181,5 @@ const AVHWAccel ff_vp9_vaapi_hwaccel = {
.uninit = ff_vaapi_decode_uninit,
.frame_params = ff_vaapi_common_frame_params,
.priv_data_size = sizeof(VAAPIDecodeContext),
-.caps_internal= HWACCEL_CAP_ASYNC_SAFE,
+.caps_internal= HWACCEL_CAP_ASYNC_SAFE |
HWACCEL_CAP_INTERNAL_ALLOC,
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/3] lavc/decode: Add get_hw_config function
On Tue, 2022-08-16 at 13:22 +0200, Anton Khirnov wrote:
> The commit message is misleading - you are not adding code, you are
> moving code.
>
> Quoting Fei Wang (2022-08-12 14:55:43)
> > From: Linjie Fu
> >
> > Wrap the procedure of getting the hardware config from a pixel
> > format
> > into a function.
> >
> > Signed-off-by: Linjie Fu
> > Signed-off-by: Fei Wang
> > ---
> > libavcodec/decode.c | 33 +
> > 1 file changed, 21 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index 75373989c6..d66d5a4160 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1156,6 +1156,26 @@ static void hwaccel_uninit(AVCodecContext
> > *avctx)
> > av_buffer_unref(&avctx->hw_frames_ctx);
> > }
> >
> > +static const AVCodecHWConfigInternal *get_hw_config(AVCodecContext
> > *avctx, enum AVPixelFormat fmt)
> > +{
> > +const AVCodecHWConfigInternal *hw_config;
> > +int i;
>
> Should be declared in the loop
>
> > +if (ffcodec(avctx->codec)->hw_configs) {
> > +for (i = 0;; i++) {
> > +hw_config = ffcodec(avctx->codec)->hw_configs[i];
> > +if (!hw_config)
> > +break;
>
> return NULL;
>
> > +if (hw_config->public.pix_fmt == fmt)
> > +break;
>
> return hw_config;
>
> > +}
> > +} else {
> > +hw_config = NULL;
> > +}
>
> You can save one level of indentation by starting with
>
> if (!ffcodec(avctx->codec)->hw_configs)
> return NULL;
Fix in V2.
Thanks
Fei
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] doc/plans: add AVWriter
Why reinventing yet another ad-hoc thing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] doc/plans: add a file to list approved projects
I am very strongly against this. You keep trying to preemptively shield your code from criticism that you're unable to deal with, rather than actually build consensus. Stop that, it will lead to nothing good for you or the project. You also keep insinuating that I'm "blocking" your precious avwriter. I am not blocking anything. You asked for opinions on it, I gave you my personal opinion. I even gave suggestions on how to proceed with it. Rather than engage with them, you started ranting at me, as you always do when someone disagrees with you, followed by melodramatic theatrics. You're going to have a bad time around here until you learn how to deal with disagreements constructively. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
