Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec
https://github.com/mpeg5/ffevc ffmpeg-subtree reflects ffmpeg repository. The main branch is synchronized to ffpmeg git repo master branch and contains all the changes provided in my last patches BR Dawid -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Friday, August 12, 2022 5:50 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec On Fri, Aug 12, 2022 at 09:12:30AM +0200, Dawid Kozinski/Robot SDK (PLT) /SRPOL/Staff Engineer/삼성전자 wrote: > If the only issue is about 'No newline at end of file', of course I will add > it and provide new patches. iam not sure what the issue was i just saw the error and didnt immedeatly see anything wrong when i looked into the file so i reported it assuming it would replroduce on your side i will recheck if theres a new version, do you have some git repro i can test so you dont have to repost this for just a line ending thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch ___ ffmpeg-devel mailing list ffmpeg-devel@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] Provided support for MPEG-5 EVC (Essential Video Coding) codec
https://github.com/mpeg5/ffevc ffmpeg-subtree reflects ffmpeg repository. The main branch is synchronized to ffpmeg git repo master branch and contains all the changes provided in my last patches BR Dawid -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Friday, August 12, 2022 5:50 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH 2/2] Provided support for MPEG-5 EVC (Essential Video Coding) codec On Fri, Aug 12, 2022 at 09:12:30AM +0200, Dawid Kozinski/Robot SDK (PLT) /SRPOL/Staff Engineer/삼성전자 wrote: > If the only issue is about 'No newline at end of file', of course I will add > it and provide new patches. iam not sure what the issue was i just saw the error and didnt immedeatly see anything wrong when i looked into the file so i reported it assuming it would replroduce on your side i will recheck if theres a new version, do you have some git repro i can test so you dont have to repost this for just a line ending thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Let us carefully observe those good qualities wherein our enemies excel us and endeavor to excel them, by avoiding what is faulty, and imitating what is excellent in them. -- Plutarch ___ ffmpeg-devel mailing list ffmpeg-devel@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] [FFmpeg-cvslog] avfilter/vsrc_ddagrab: add options for more control over output format fallback
On 2022-08-13 07:05 pm, Timo Rothenpieler wrote:
ffmpeg | branch: master | Timo Rothenpieler | Sun Aug
7 23:14:09 2022 +0200| [c469c3c3b18fbacd6ee0165573034d2a0408b83f] | committer: Timo
Rothenpieler
avfilter/vsrc_ddagrab: add options for more control over output format fallback
http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=c469c3c3b18fbacd6ee0165573034d2a0408b83f
---
libavfilter/version.h | 2 +-
libavfilter/vsrc_ddagrab.c | 12 +---
doc/filters.texi update needed.
Regards,
Gyan
2 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/libavfilter/version.h b/libavfilter/version.h
index fa67606495..f3c1964cac 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -32,7 +32,7 @@
#include "version_major.h"
#define LIBAVFILTER_VERSION_MINOR 46
-#define LIBAVFILTER_VERSION_MICRO 102
+#define LIBAVFILTER_VERSION_MICRO 103
#define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
diff --git a/libavfilter/vsrc_ddagrab.c b/libavfilter/vsrc_ddagrab.c
index 252505b96d..00c72187ea 100644
--- a/libavfilter/vsrc_ddagrab.c
+++ b/libavfilter/vsrc_ddagrab.c
@@ -98,6 +98,8 @@ typedef struct DdagrabContext {
intoffset_x;
intoffset_y;
intout_fmt;
+intallow_fallback;
+intforce_fmt;
} DdagrabContext;
#define OFFSET(x) offsetof(DdagrabContext, x)
@@ -117,6 +119,10 @@ static const AVOption ddagrab_options[] = {
{ "x2bgr10","only output 10 Bit X2BGR10",0,
AV_OPT_TYPE_CONST, { .i64 = DXGI_FORMAT_R10G10B10A2_UNORM }, 0, INT_MAX, FLAGS, "output_fmt" },
{ "16bit", "only output default 16 Bit format", 0,
AV_OPT_TYPE_CONST, { .i64 = DXGI_FORMAT_R16G16B16A16_FLOAT },0, INT_MAX, FLAGS, "output_fmt" },
{ "rgbaf16","only output 16 Bit RGBAF16",0,
AV_OPT_TYPE_CONST, { .i64 = DXGI_FORMAT_R16G16B16A16_FLOAT },0, INT_MAX, FLAGS, "output_fmt" },
+{ "allow_fallback", "don't error on fallback to default 8 Bit format",
+ OFFSET(allow_fallback),
AV_OPT_TYPE_BOOL, { .i64 = 0}, 0, 1, FLAGS },
+{ "force_fmt", "exclude BGRA from format list (experimental, discouraged by
Microsoft)",
+ OFFSET(force_fmt),
AV_OPT_TYPE_BOOL, { .i64 = 0}, 0, 1, FLAGS },
{ NULL }
};
@@ -226,7 +232,7 @@ static av_cold int init_dxgi_dda(AVFilterContext *avctx)
} else if (dda->out_fmt) {
formats[0] = dda->out_fmt;
formats[1] = DXGI_FORMAT_B8G8R8A8_UNORM;
-nb_formats = 2;
+nb_formats = dda->force_fmt ? 1 : 2;
}
IDXGIOutput_Release(dxgi_output);
@@ -262,7 +268,7 @@ static av_cold int init_dxgi_dda(AVFilterContext *avctx)
#else
{
#endif
-if (dda->out_fmt && dda->out_fmt != DXGI_FORMAT_B8G8R8A8_UNORM) {
+if (dda->out_fmt && dda->out_fmt != DXGI_FORMAT_B8G8R8A8_UNORM &&
(!dda->allow_fallback || dda->force_fmt)) {
av_log(avctx, AV_LOG_ERROR, "Only 8 bit output supported with legacy
API\n");
return AVERROR(ENOTSUP);
}
@@ -733,7 +739,7 @@ static int ddagrab_config_props(AVFilterLink *outlink)
if (ret < 0)
return ret;
-if (dda->out_fmt && dda->raw_format != dda->out_fmt) {
+if (dda->out_fmt && dda->raw_format != dda->out_fmt && (!dda->allow_fallback
|| dda->force_fmt)) {
av_log(avctx, AV_LOG_ERROR, "Requested output format unavailable.\n");
return AVERROR(ENOTSUP);
}
___
ffmpeg-cvslog mailing list
ffmpeg-cvs...@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
To unsubscribe, visit link above, or email
ffmpeg-cvslog-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] [FFmpeg-cvslog] avfilter/vsrc_ddagrab: add options for more control over output format fallback
On 13.08.2022 15:51, Gyan Doshi wrote: On 2022-08-13 07:05 pm, Timo Rothenpieler wrote: ffmpeg | branch: master | Timo Rothenpieler | Sun Aug 7 23:14:09 2022 +0200| [c469c3c3b18fbacd6ee0165573034d2a0408b83f] | committer: Timo Rothenpieler avfilter/vsrc_ddagrab: add options for more control over output format fallback http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=c469c3c3b18fbacd6ee0165573034d2a0408b83f --- libavfilter/version.h | 2 +- libavfilter/vsrc_ddagrab.c | 12 +--- doc/filters.texi update needed. It's intentionally omitted for now, until the format is actually useful. ___ ffmpeg-devel mailing list ffmpeg-devel@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/6] avcodec/avcodec: Move initializing frame-thrd encoder to encode_preinit
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 6 --
libavcodec/encode.c | 6 ++
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index f82d9e9f74..0451f57f82 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -283,12 +283,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (ret < 0)
goto free_and_end;
-if (CONFIG_FRAME_THREAD_ENCODER && av_codec_is_encoder(avctx->codec)) {
-ret = ff_frame_thread_encoder_init(avctx);
-if (ret < 0)
-goto free_and_end;
-}
-
if (HAVE_THREADS
&& !(avci->frame_thread_encoder &&
(avctx->active_thread_type&FF_THREAD_FRAME))) {
/* Frame-threaded decoders call FFCodec.init for their child contexts.
*/
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 7919b165da..bd66f138a3 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -668,6 +668,12 @@ int ff_encode_preinit(AVCodecContext *avctx)
return AVERROR(ENOMEM);
}
+if (CONFIG_FRAME_THREAD_ENCODER) {
+ret = ff_frame_thread_encoder_init(avctx);
+if (ret < 0)
+return ret;
+}
+
return 0;
}
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6] avcodec/avcodec: Remove redundant check
At this point active_thread_type is set iff active_thread_type
is set to FF_THREAD_FRAME iff AVCodecInternal.frame_thread_encoder
is set.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/avcodec.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.c b/libavcodec/avcodec.c
index 0451f57f82..29643199be 100644
--- a/libavcodec/avcodec.c
+++ b/libavcodec/avcodec.c
@@ -283,8 +283,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
if (ret < 0)
goto free_and_end;
-if (HAVE_THREADS
-&& !(avci->frame_thread_encoder &&
(avctx->active_thread_type&FF_THREAD_FRAME))) {
+if (HAVE_THREADS && !avci->frame_thread_encoder) {
/* Frame-threaded decoders call FFCodec.init for their child contexts.
*/
lock_avcodec(codec2);
ret = ff_thread_init(avctx);
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6] avcodec/mpegpicture: Don't copy unnecessarily, fix race
mpegvideo uses an array of Pictures and when it is done with using
them, it only unreferences them incompletely: Some buffers are kept
so that they can be reused lateron if the same slot in the Picture
array is reused, making this a sort of a bufferpool.
(Basically, a Picture is considered used if the AVFrame's buf is set.)
Yet given that other pieces of the decoder may have a reference to
these buffers, they need not be writable and are made writable using
av_buffer_make_writable() when preparing a new Picture. This involves
reading the buffer's data, although the old content of the buffer
need not be retained.
Worse, this read can be racy, because the buffer can be used by another
thread at the same time. This happens for Real Video 3 and 4.
This commit fixes this race by no longer copying the data;
instead the old buffer is replaced by a new, zero-allocated buffer.
(Here are the details of what happens with three or more decoding threads
when decoding rv30.rm from the FATE-suite as happens in the rv30 test:
The first decoding thread uses the first slot of its picture array
to store its current pic; update_thread_context copies this for the
second thread that decodes a P-frame. It uses the second slot in its
Picture array to store its P-frame. This arrangement is then copied
to the third decode thread, which decodes a B-frame. It uses the third
slot in its Picture array for its current frame.
update_thread_context copies this to the next thread. It unreferences
the third slot containing the other B-frame and then it reuses this
slot for its current frame. Because the pic array slots are only
incompletely unreferenced, the buffers of the previous B-frame are
still in there and they are not writable; in fact the previous
thread is concurrently writing to them, causing races when making
the buffer writable.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegpicture.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index 2192f74cea..ed96abbe2d 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -47,11 +47,25 @@ static void av_noinline free_picture_tables(Picture *pic)
}
}
+static int make_table_writable(AVBufferRef **ref)
+{
+AVBufferRef *old = *ref, *new;
+
+if (av_buffer_is_writable(old))
+return 0;
+new = av_buffer_allocz(old->size);
+if (!new)
+return AVERROR(ENOMEM);
+av_buffer_unref(ref);
+*ref = new;
+return 0;
+}
+
static int make_tables_writable(Picture *pic)
{
#define MAKE_WRITABLE(table) \
do {\
-int ret = av_buffer_make_writable(&pic->table); \
+int ret = make_table_writable(&pic->table); \
if (ret < 0) \
return ret; \
} while (0)
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] avcodec/mpegpicture: Always reset motion val buffer
Codecs call ff_find_unused_picture() to get the index of
an unused picture; said picture may have buffers left
from using it previously (these buffers are intentionally
not unreferenced so that it might be possible to reuse them;
this is mpegvideo's version of a bufferpool). They should
not make any assumptions about which picture they get.
Yet somehow this is not true when decoding OBMC: Returning
random empty pictures (instead of the first one) leads
to nondeterministic results; similarly, explicitly
rezeroing the buffer before handing it over to the codec
changes the outcome of the h263-obmc tests, but it makes it
independent of the returned pictures. Therefore this commit
does so.
(No, this commit is not intended to be applied. I just hope
to arouse the interest of people familiar with H.263
to look at this issue.)
Signed-off-by: Andreas Rheinhardt
---
I still don't intend to apply this. If no one looks into this,
I will just add the necessary changes to the h263-obmc ref-files
in the next commit and leave this one out.
libavcodec/mpegpicture.c | 4
tests/ref/vsynth/vsynth1-h263-obmc | 4 ++--
tests/ref/vsynth/vsynth2-h263-obmc | 4 ++--
tests/ref/vsynth/vsynth_lena-h263-obmc | 4 ++--
4 files changed, 10 insertions(+), 6 deletions(-)
diff --git a/libavcodec/mpegpicture.c b/libavcodec/mpegpicture.c
index c57f149752..2192f74cea 100644
--- a/libavcodec/mpegpicture.c
+++ b/libavcodec/mpegpicture.c
@@ -280,6 +280,10 @@ int ff_alloc_picture(AVCodecContext *avctx, Picture *pic,
MotionEstContext *me,
for (i = 0; i < 2; i++) {
pic->motion_val[i] = (int16_t (*)[2])pic->motion_val_buf[i]->data
+ 4;
pic->ref_index[i] = pic->ref_index_buf[i]->data;
+/* FIXME: The output of H.263 with OBMC depends upon
+ * the earlier content of the buffer; therefore we
+ * reset it here. */
+memset(pic->motion_val_buf[i]->data, 0,
pic->motion_val_buf[i]->size);
}
}
diff --git a/tests/ref/vsynth/vsynth1-h263-obmc
b/tests/ref/vsynth/vsynth1-h263-obmc
index b7a267a8cb..aed283ed53 100644
--- a/tests/ref/vsynth/vsynth1-h263-obmc
+++ b/tests/ref/vsynth/vsynth1-h263-obmc
@@ -1,4 +1,4 @@
7dec64380f375e5118b66f3b1e24 *tests/data/fate/vsynth1-h263-obmc.avi
657320 tests/data/fate/vsynth1-h263-obmc.avi
-844f7ee27fa122e199fe20987b41a15c
*tests/data/fate/vsynth1-h263-obmc.out.rawvideo
-stddev:8.16 PSNR: 29.89 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
diff --git a/tests/ref/vsynth/vsynth2-h263-obmc
b/tests/ref/vsynth/vsynth2-h263-obmc
index 2cef7f551b..c0dcc3239e 100644
--- a/tests/ref/vsynth/vsynth2-h263-obmc
+++ b/tests/ref/vsynth/vsynth2-h263-obmc
@@ -1,4 +1,4 @@
2d8a58b295e03f94e6a41468b2d3909e *tests/data/fate/vsynth2-h263-obmc.avi
208522 tests/data/fate/vsynth2-h263-obmc.avi
-4a939ef99fc759293f2e609bfcacd2a4
*tests/data/fate/vsynth2-h263-obmc.out.rawvideo
-stddev:6.10 PSNR: 32.41 MAXDIFF: 90 bytes: 7603200/ 7603200
+3500b4227c1e6309ca5213414599266f
*tests/data/fate/vsynth2-h263-obmc.out.rawvideo
+stddev:6.19 PSNR: 32.29 MAXDIFF: 111 bytes: 7603200/ 7603200
diff --git a/tests/ref/vsynth/vsynth_lena-h263-obmc
b/tests/ref/vsynth/vsynth_lena-h263-obmc
index 5b963107f6..78d7cc7277 100644
--- a/tests/ref/vsynth/vsynth_lena-h263-obmc
+++ b/tests/ref/vsynth/vsynth_lena-h263-obmc
@@ -1,4 +1,4 @@
3c6946f808412ac320be9e0c36051ea2 *tests/data/fate/vsynth_lena-h263-obmc.avi
154730 tests/data/fate/vsynth_lena-h263-obmc.avi
-588d992d9d8096da8bdc5027268da914
*tests/data/fate/vsynth_lena-h263-obmc.out.rawvideo
-stddev:5.39 PSNR: 33.49 MAXDIFF: 82 bytes: 7603200/ 7603200
+737af7fb166e2260ba049ae6bc30673d
*tests/data/fate/vsynth_lena-h263-obmc.out.rawvideo
+stddev:5.42 PSNR: 33.44 MAXDIFF: 77 bytes: 7603200/ 7603200
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 5/6] avcodec/mpegvideodec: Constify some functions
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpegvideo_dec.c | 4 ++--
libavcodec/mpegvideodec.h | 4 ++--
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/mpegvideo_dec.c b/libavcodec/mpegvideo_dec.c
index 93ba4e31b3..7566fe69f9 100644
--- a/libavcodec/mpegvideo_dec.c
+++ b/libavcodec/mpegvideo_dec.c
@@ -497,14 +497,14 @@ void ff_mpv_frame_end(MpegEncContext *s)
ff_thread_report_progress(&s->current_picture_ptr->tf, INT_MAX, 0);
}
-void ff_print_debug_info(MpegEncContext *s, Picture *p, AVFrame *pict)
+void ff_print_debug_info(const MpegEncContext *s, const Picture *p, AVFrame
*pict)
{
ff_print_debug_info2(s->avctx, pict, s->mbskip_table, p->mb_type,
p->qscale_table, p->motion_val,
s->mb_width, s->mb_height, s->mb_stride,
s->quarter_sample);
}
-int ff_mpv_export_qp_table(MpegEncContext *s, AVFrame *f, Picture *p, int
qp_type)
+int ff_mpv_export_qp_table(const MpegEncContext *s, AVFrame *f, const Picture
*p, int qp_type)
{
AVVideoEncParams *par;
int mult = (qp_type == FF_MPV_QSCALE_TYPE_MPEG1) ? 2 : 1;
diff --git a/libavcodec/mpegvideodec.h b/libavcodec/mpegvideodec.h
index fabc1b2202..250034b486 100644
--- a/libavcodec/mpegvideodec.h
+++ b/libavcodec/mpegvideodec.h
@@ -53,12 +53,12 @@ int ff_mpv_frame_start(MpegEncContext *s, AVCodecContext
*avctx);
void ff_mpv_report_decode_progress(MpegEncContext *s);
void ff_mpv_frame_end(MpegEncContext *s);
-int ff_mpv_export_qp_table(MpegEncContext *s, AVFrame *f, Picture *p, int
qp_type);
+int ff_mpv_export_qp_table(const MpegEncContext *s, AVFrame *f, const Picture
*p, int qp_type);
int ff_mpeg_update_thread_context(AVCodecContext *dst, const AVCodecContext
*src);
void ff_mpeg_draw_horiz_band(MpegEncContext *s, int y, int h);
void ff_mpeg_flush(AVCodecContext *avctx);
-void ff_print_debug_info(MpegEncContext *s, Picture *p, AVFrame *pict);
+void ff_print_debug_info(const MpegEncContext *s, const Picture *p, AVFrame
*pict);
static inline int mpeg_get_qscale(MpegEncContext *s)
{
--
2.34.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] avcodec/mpegvideo: Don't zero unnecessarily
Signed-off-by: Andreas Rheinhardt --- libavcodec/mpegvideo.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavcodec/mpegvideo.c b/libavcodec/mpegvideo.c index ff08168362..1190f29954 100644 --- a/libavcodec/mpegvideo.c +++ b/libavcodec/mpegvideo.c @@ -651,10 +651,10 @@ int ff_mpv_init_context_frame(MpegEncContext *s) s->dc_val_base[i] = 1024; } -/* which mb is an intra block, init macroblock skip table */ -if (!(s->mbintra_table = av_mallocz(mb_array_size)) || -// Note the + 1 is for a quicker MPEG-4 slice_end detection -!(s->mbskip_table = av_mallocz(mb_array_size + 2))) +// Note the + 1 is for a quicker MPEG-4 slice_end detection +if (!(s->mbskip_table = av_mallocz(mb_array_size + 2)) || +/* which mb is an intra block, init macroblock skip table */ +!(s->mbintra_table = av_malloc(mb_array_size))) return AVERROR(ENOMEM); memset(s->mbintra_table, 1, mb_array_size); -- 2.34.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] fftools/ffmpeg: store a separate copy of input codec parameters
Use it instead of AVStream.codecpar in the main thread. While
AVStream.codecpar is documented to only be updated when the stream is
added or avformat_find_stream_info(), it is actually updated during
demuxing. Accessing it from a different thread then constitutes a race.
Ideally, some mechanism should eventually be provided for signalling
parameter updates to the user. Then the demuxing thread could pick up
the changes and propagate them to the decoder.
---
fftools/ffmpeg.c | 39 ---
fftools/ffmpeg.h | 6 ++
fftools/ffmpeg_opt.c | 6 +-
3 files changed, 31 insertions(+), 20 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8eb7759392..ef7177fc33 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -608,6 +608,7 @@ static void ffmpeg_cleanup(int ret)
av_freep(&ist->dts_buffer);
avcodec_free_context(&ist->dec_ctx);
+avcodec_parameters_free(&ist->par);
av_freep(&input_streams[i]);
}
@@ -1492,7 +1493,7 @@ static void print_final_stats(int64_t total_size)
for (j = 0; j < f->nb_streams; j++) {
InputStream *ist = input_streams[f->ist_index + j];
-enum AVMediaType type = ist->st->codecpar->codec_type;
+enum AVMediaType type = ist->par->codec_type;
total_size+= ist->data_size;
total_packets += ist->nb_packets;
@@ -1809,7 +1810,7 @@ static void flush_encoders(void)
for (x = 0; x < fg->nb_inputs; x++) {
InputFilter *ifilter = fg->inputs[x];
if (ifilter->format < 0 &&
-ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar) < 0) {
+ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->par) < 0) {
av_log(NULL, AV_LOG_ERROR, "Error copying paramerets
from input stream\n");
exit_program(1);
}
@@ -1912,11 +1913,11 @@ static void do_streamcopy(InputStream *ist,
OutputStream *ost, const AVPacket *p
if (pkt->dts == AV_NOPTS_VALUE) {
opkt->dts = av_rescale_q(ist->dts, AV_TIME_BASE_Q, ost->mux_timebase);
} else if (ost->st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-int duration = av_get_audio_frame_duration2(ist->st->codecpar,
pkt->size);
+int duration = av_get_audio_frame_duration2(ist->par, pkt->size);
if(!duration)
-duration = ist->st->codecpar->frame_size;
+duration = ist->par->frame_size;
opkt->dts = av_rescale_delta(ist->st->time_base, pkt->dts,
-(AVRational){1,
ist->st->codecpar->sample_rate}, duration,
+(AVRational){1, ist->par->sample_rate},
duration,
&ist->filter_in_rescale_delta_last,
ost->mux_timebase);
/* dts will be set immediately afterwards to what pts is now */
opkt->pts = opkt->dts - ost_tb_start_time;
@@ -1976,7 +1977,7 @@ static int ifilter_send_frame(InputFilter *ifilter,
AVFrame *frame, int keep_ref
/* determine if the parameters for this input changed */
need_reinit = ifilter->format != frame->format;
-switch (ifilter->ist->st->codecpar->codec_type) {
+switch (ifilter->ist->par->codec_type) {
case AVMEDIA_TYPE_AUDIO:
need_reinit |= ifilter->sample_rate!= frame->sample_rate ||
av_channel_layout_compare(&ifilter->ch_layout,
&frame->ch_layout);
@@ -2056,7 +2057,7 @@ static int ifilter_send_eof(InputFilter *ifilter, int64_t
pts)
} else {
// the filtergraph was never configured
if (ifilter->format < 0) {
-ret = ifilter_parameters_from_codecpar(ifilter,
ifilter->ist->st->codecpar);
+ret = ifilter_parameters_from_codecpar(ifilter, ifilter->ist->par);
if (ret < 0)
return ret;
}
@@ -2212,9 +2213,9 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
// The following line may be required in some cases where there is no
parser
// or the parser does not has_b_frames correctly
-if (ist->st->codecpar->video_delay < ist->dec_ctx->has_b_frames) {
+if (ist->par->video_delay < ist->dec_ctx->has_b_frames) {
if (ist->dec_ctx->codec_id == AV_CODEC_ID_H264) {
-ist->st->codecpar->video_delay = ist->dec_ctx->has_b_frames;
+ist->par->video_delay = ist->dec_ctx->has_b_frames;
} else
av_log(ist->dec_ctx, AV_LOG_WARNING,
"video_delay is larger in decoder than demuxer %d > %d.\n"
@@ -,7 +2223,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt,
int *got_output, int64_
"of this file to https://streams.videolan.org/upload/ "
"and contact the ffmpeg-devel mailing list.
(ffmpeg-devel@ffmpeg.org)\n",
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On Fri, Aug 12, 2022 at 07:21:02PM +0200, Timo Rothenpieler wrote: > On 12.08.2022 19:18, Michael Niedermayer wrote: > > And i dont think removing IPFS support entirely from FFmpeg is a smart > > choice. > > I wouldn't at all be upset about having proper IPFS support in FFmpeg, > there's no argument there. > > The issue is that this has very little to do with actual/native IPFS > support, but it's just a url rewriter, which on top of that comes with a > hardcoded in default gateway. Which is run by a to me unknown company, with > unknown interests. I fully support better IPFS support what iam a bit "upset" about is that running a IPFS node is presented as if that was more private than using a gateway. If you use a gateway there are 2 options A. the gateway is honest then you have decent privacy B. the gateway logs you, in which case you have no privacy OTOH if you run a node You have no privacy either way Consider this: If i want to know who downloads assetXYZ i can simple create 1000 nodes each sharing assetXYZ. (this can in reality be 1 node pretending to be 1000) If you now request assetXYZ from IPFS then the node you use will likely download it straight from one of my 1000 nodes, i get your IP, yes we have a encrypted connection but that goes straight to my attack nodes you notice nothing of this, i log your IP and time. If you used some public gateway, i would just log the time and IP of that public gateway If you want really private IPFS with you need TOR or something equivalent. If someone posts a patch to add native TOR support i surely wont be unhappy I also would very welcome more native IPFS support but that alone does not fix the privacy / logging issue Also i would be VERY happy if iam wrong and running a IPFS node can be made 100% secure and private independant of this, i would very much welcome the current gateway code to be extended to verify the content so the gateway cannot modify it! And this should be enabled for non local gateways by default i think thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] ipfsgateway: Remove default gateway
On 13.08.2022 18:29, Michael Niedermayer wrote: I fully support better IPFS support what iam a bit "upset" about is that running a IPFS node is presented as if that was more private than using a gateway. That's not what people are suggesting. The primary upset is about FFmpeg having hardcoded in a public gateway run by some company. That is unprecedented for FFmpeg. You have to keep in mind that that code will make it into a ton of distros, installed applications and who knows what else, for a very long time to come. What if in 5 years that company goes under, and the domain is sold? Or it just decides to "become evil"? What if it already is? I don't know that company, or how they earn their money with running a public service like that. There are so many issues with hardcoding a domain like that into FFmpeg, that I'm surprised really anyone is defending it. If you use a gateway there are 2 options A. the gateway is honest then you have decent privacy B. the gateway logs you, in which case you have no privacy OTOH if you run a node You have no privacy either way If you run a node, you have put enough effort in, that you at least understand what is happening. People understand torrents, which have the same issue, and manage to use them. Consider this: If i want to know who downloads assetXYZ i can simple create 1000 nodes each sharing assetXYZ. (this can in reality be 1 node pretending to be 1000) If you now request assetXYZ from IPFS then the node you use will likely download it straight from one of my 1000 nodes, i get your IP, yes we have a encrypted connection but that goes straight to my attack nodes you notice nothing of this, i log your IP and time. If you used some public gateway, i would just log the time and IP of that public gateway If you want really private IPFS with you need TOR or something equivalent. If someone posts a patch to add native TOR support i surely wont be unhappy I also would very welcome more native IPFS support but that alone does not fix the privacy / logging issue Also i would be VERY happy if iam wrong and running a IPFS node can be made 100% secure and private I don't really understand how that is at all relevant to the issue at hand: We have hardcoded a companies server into our main codebase. Thus we endorse that company and basically say that we trust it. Which I for one do not. I don't know it at all. If it turns out that company is acting badly, it will also reflect badly on the project. We, as a project, simply cannot do that. It's easy to say that "a user will just pick the first gateway found on google anyway", but we cannot safe users from their own responsibility there. It's our responsibility to be trustworthy. Hardcoding servers like this does not instill trust. Specially if the IPFS project then publishes a big blog post about ffmpeg having gained "native" support, which makes the whole effort appear even more dubious, since the support that was added is very much not native. independant of this, i would very much welcome the current gateway code to be extended to verify the content so the gateway cannot modify it! And this should be enabled for non local gateways by default i think Seems like a good idea in any case. No idea how ipfs works, but does the url not work as hash for the contents it points to? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/5] avcodec/mjpegdec: bayer and rct are incompatible
Fixes: out of array read
Fixes:
49434/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5208501080686592
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpegdec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5f058d026f..65c3c402a2 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1092,6 +1092,10 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
return AVERROR_INVALIDDATA;
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
+if (s->bayer) {
+if (s->rct || s->pegasus_rct)
+return AVERROR_INVALIDDATA;
+}
s->restart_count = s->restart_interval;
@@ -1942,6 +1946,8 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
}
len -= 9;
+if (s->bayer)
+goto out;
if (s->got_picture)
if (rgb != s->rgb || pegasus_rct != s->pegasus_rct) {
av_log(s->avctx, AV_LOG_WARNING, "Mismatching LJIF tag\n");
--
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 4/5] avformat/subviewerdec: Make read_ts() more flexible
Fixes: signed integer overflow: -1948269928 * 10 cannot be represented in type
'int'
Fixes:
49451/clusterfuzz-testcase-minimized-ffmpeg_dem_SUBVIEWER_fuzzer-6344614822412288
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
---
libavformat/subviewerdec.c | 36 +---
1 file changed, 21 insertions(+), 15 deletions(-)
diff --git a/libavformat/subviewerdec.c b/libavformat/subviewerdec.c
index e3a950fce3..6ffdc98c39 100644
--- a/libavformat/subviewerdec.c
+++ b/libavformat/subviewerdec.c
@@ -50,26 +50,32 @@ static int subviewer_probe(const AVProbeData *p)
return 0;
}
+static int get_multiplier(int e) {
+switch (e) {
+case 1 : return 100;
+case 2 : return 10;
+case 3 : return 1;
+default : return -1;
+}
+}
+
static int read_ts(const char *s, int64_t *start, int *duration)
{
int64_t end;
int hh1, mm1, ss1, ms1;
int hh2, mm2, ss2, ms2;
-int multiplier = 1;
-
-if (sscanf(s, "%u:%u:%u.%2u,%u:%u:%u.%2u",
- &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
-multiplier = 10;
-} else if (sscanf(s, "%u:%u:%u.%1u,%u:%u:%u.%1u",
- &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
-multiplier = 100;
-}
-if (sscanf(s, "%u:%u:%u.%u,%u:%u:%u.%u",
- &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
-ms1 = FFMIN(ms1, 999);
-ms2 = FFMIN(ms2, 999);
-end= (hh2*3600LL + mm2*60LL + ss2) * 1000LL + ms2 * multiplier;
-*start = (hh1*3600LL + mm1*60LL + ss1) * 1000LL + ms1 * multiplier;
+int multiplier1, multiplier2;
+int ms1p1, ms1p2, ms2p1, ms2p2;
+
+if (sscanf(s, "%u:%u:%u.%n%u%n,%u:%u:%u.%n%u%n",
+ &hh1, &mm1, &ss1, &ms1p1, &ms1, &ms1p2, &hh2, &mm2, &ss2,
&ms2p1, &ms2, &ms2p2) == 8) {
+multiplier1 = get_multiplier(ms1p2 - ms1p1);
+multiplier2 = get_multiplier(ms2p2 - ms2p1);
+if (multiplier1 <= 0 ||multiplier2 <= 0)
+return -1;
+
+end= (hh2*3600LL + mm2*60LL + ss2) * 1000LL + ms2 * multiplier2;
+*start = (hh1*3600LL + mm1*60LL + ss1) * 1000LL + ms1 * multiplier1;
*duration = end - *start;
return 0;
}
--
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 1/5] tools/target_dec_fuzzer: Adjust threshold for VMDVIDEO
Fixes: Timeout
Fixes:
49350/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDVIDEO_fuzzer-4554761801695232
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e55d9fc7eb..861d201a3d 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -281,6 +281,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_VC1: maxpixels /= 8192; break;
case AV_CODEC_ID_VC1IMAGE:maxpixels /= 8192; break;
case AV_CODEC_ID_VMNC:maxpixels /= 8192; break;
+case AV_CODEC_ID_VMDVIDEO:maxpixels /= 1024; break;
case AV_CODEC_ID_VP3: maxpixels /= 4096; break;
case AV_CODEC_ID_VP4: maxpixels /= 4096; break;
case AV_CODEC_ID_VP5: maxpixels /= 256; break;
--
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 5/5] avcodec/4xm: treat AV_LOG_ERROR cases as errors
Fixes: Timeout
Fixes:
49504/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FOURXM_fuzzer-57045777054
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/4xm.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/4xm.c b/libavcodec/4xm.c
index 8941d715fa..a7c9043b0a 100644
--- a/libavcodec/4xm.c
+++ b/libavcodec/4xm.c
@@ -950,9 +950,11 @@ static int decode_frame(AVCodecContext *avctx, AVFrame
*picture,
} else if (frame_4cc == AV_RL32("snd_")) {
av_log(avctx, AV_LOG_ERROR, "ignoring snd_ chunk length:%d\n",
buf_size);
+return AVERROR_INVALIDDATA;
} else {
av_log(avctx, AV_LOG_ERROR, "ignoring unknown chunk length:%d\n",
buf_size);
+return AVERROR_INVALIDDATA;
}
picture->key_frame = picture->pict_type == AV_PICTURE_TYPE_I;
--
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/5] tools/target_dec_fuzzer: Adjust threshold for VB
Fixes: Timeout
Fixes:
49372/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VB_fuzzer-5234505337667584
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 861d201a3d..e1b5d2b3c1 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -278,6 +278,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
case AV_CODEC_ID_TQI: maxpixels /= 1024; break;
case AV_CODEC_ID_TRUEMOTION2: maxpixels /= 1024; break;
case AV_CODEC_ID_TSCC:maxpixels /= 1024; break;
+case AV_CODEC_ID_VB: maxpixels /= 1024; break;
case AV_CODEC_ID_VC1: maxpixels /= 8192; break;
case AV_CODEC_ID_VC1IMAGE:maxpixels /= 8192; break;
case AV_CODEC_ID_VMNC:maxpixels /= 8192; break;
--
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] lavu/tx: implement aarch64 NEON SIMD
The fastest fast Fourier transform in not just the west, but the world, now for the most popular toy ISA. On a high level, it follows the design of the AVX2 version closely, with the exception that the input is slightly less permuted as we don't have to do lane switching with the input on double 4pt and 8pt. On a low level, the lack of subadd/addsub instructions REALLY penalizes any attempt at writing an FFT. That single register matters a _lot_, and reloading it simply takes unacceptably long. In x86 land, vendors would've noticed developers need this. In ARM land, you get a badly designed complex multiplication instruction we cannot use, that's not present on 95% of devices. Because only compilers matter, right? There's still room for improvement. I think using stp instead of st1 may help in a few places, some reordering may help performance in the recombination macro, and there are other TODOs I've left marked in the code. There are also a few places where the limited range on immediates in adds may be worked around. All timings below are in cycles: A53: Length | C | New (lavu) | Old (lavc) | FFTW -- |-|-|-|- 4 | 842 | 420 | 1210 | 1460 8 | 1538 | 1020 | 1850 | 2520 16 | 3717 | 1900 | 3700 | 3990 32 | 9156 | 4070 | 8289 | 8860 64 | 21160 | 9931 | 18600 | 19625 128 | 49180 | 23278 | 41922 | 41922 256 | 112073 | 53876 | 93202 | 101092 512 | 252864 | 122884 | 205897 | 207868 1024 | 560512 | 278322 | 458071 | 453053 2048 | 1295402 | 775835 | 1038205 | 1020265 4096 | 3281263 | 2021221 | 2409718 | 2577554 8192 | 8577845 | 4780526 | 5673041 | 6802722 Apple M1 New - Total for len 512 reps 2097152 = 1.459141 s Old - Total for len 512 reps 2097152 = 2.251344 s FFTW - Total for len 512 reps 2097152 = 1.868429 s New - Total for len 1024 reps 4194304 = 6.490080 s Old - Total for len 1024 reps 4194304 = 9.604949 s FFTW - Total for len 1024 reps 4194304 = 7.889281 s New - Total for len 16384 reps 262144 = 10.374001 s Old - Total for len 16384 reps 262144 = 15.266713 s FFTW - Total for len 16384 reps 262144 = 12.341745 s New - Total for len 65536 reps 8192 = 1.769812 s Old - Total for len 65536 reps 8192 = 4.209413 s FFTW - Total for len 65536 reps 8192 = 3.012365 s New - Total for len 131072 reps 4096 = 1.942836 s Old - Segfaults FFTW - Total for len 131072 reps 4096 = 3.713713 s Patch attached. >From 17b2c568e526fdac46cfe98d962809f9816f4609 Mon Sep 17 00:00:00 2001 From: Lynne Date: Thu, 3 Feb 2022 11:27:03 + Subject: [PATCH] lavu/tx: implement aarch64 NEON SIMD The fastest fast Fourier transform in not just the west, but the world, now for the most popular toy ISA. On a high level, it follows the design of the AVX2 version closely, with the exception that the input is slightly less permuted as we don't have to do lane switching with the input on double 4pt and 8pt. On a low level, the lack of subadd/addsub instructions REALLY penalizes any attempt at writing an FFT. That single register matters a lot, and reloading it simply takes unacceptably long. In x86 land, vendors would've noticed developers need this. In ARM land, you get a badly designed complex multiplication instruction we cannot use, that's not present on 95% of devices. Because only compilers matter, right? All timings below are in cycles: A53: Length | C | New (lavu) | Old (lavc) | FFTW -- |-|-|-|- 4 | 842 | 420 | 1210| 1460 8 |1538 | 1020| 1850| 2520 16 |3717 | 1900| 3700| 3990 32 |9156 | 4070| 8289| 8860 64 | 21160 | 9931| 18600 | 19625 128| 49180 | 23278 | 41922 | 41922 256| 112073 | 53876 | 93202 | 101092 512| 252864 | 122884 | 205897 | 207868 1024 | 560512 | 278322 | 458071 | 453053 2048 | 1295402 | 775835 | 1038205 | 1020265 4096 | 3281263 | 2021221 | 2409718 | 2577554 8192 | 8577845 | 4780526 | 5673041 | 6802722 Apple M1 New - Total for len 512 reps 2097152 = 1.459141 s Old - Total for len 512 reps 2097152 = 2.251344 s FFTW - Total for len 512 reps 2097152 = 1.868429 s New - Total for len 1024 reps 4194304 = 6.490080 s Old - Total for len 1024 reps 4194304 = 9.604949 s FFTW - Total for len 1024 reps 4194304 = 7.889281 s New - Total for len 16384 reps 262144 = 10.374001 s Old - Total for len 16384 reps 262144 = 15.266713 s FFTW - Total for len 16384 reps 262144 = 12.341745 s New - Total for len 65536 reps 8192 = 1.769812 s Old - Total for len 65536 reps 8192 = 4.209413 s FFTW - Total for len 65536 re
Re: [FFmpeg-devel] [PATCH v2] mov: Compare frag times in correct time base when seeking a stream without a corresponding sidx
On Fri, 2022-08-12 at 16:22 +0100, Derek Buitenhuis wrote:
> On 8/9/2022 10:38 AM, "zhilizhao(赵志立)" wrote:
> > It’s suspicious to return a timestamp with unknown timebase.
>
> Would you suggest erroring in the case where there's no frag_stream?
> That could
> make sense.
Or just continue the loop, and print a warning message maybe?
@@ -1288,28 +1291,25 @@ static int64_t get_frag_time(MOVFragmentIndex
*frag_index,
}
for (i = 0; i < frag_index->item[index].nb_stream_info; i++) {
+AVStream *frag_stream = NULL;
frag_stream_info = &frag_index->item[index].stream_info[i];
+for (j = 0; j < s->nb_streams; j++)
+if (s->streams[j]->id == frag_stream_info->id)
+frag_stream = s->streams[j];
+if (!frag_stream)
+continue;
timestamp = get_stream_info_time(frag_stream_info);
if (timestamp != AV_NOPTS_VALUE)
-return timestamp;
+return av_rescale_q(timestamp, frag_stream->time_base,
dst_st->time_base);
}
return AV_NOPTS_VALUE;
}
>
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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".
