[FFmpeg-devel] [SDR][RFC] libavradio branch changes
Hi
the new libavradio in its new repository needs some changes the problem
is that maintaining it in a separate repository AND seperate directory is not
so simple
But let me show this in numbers, this is the stats of the changes related to
the build
system that would need to be maintained:
commit e262fd4b85a1a3ddf34c365bb88e54cdc6be53eb
Author: Michael Niedermayer
Date: Sun Jul 2 14:08:42 2023 +0200
Move sdr to new libavradio
Signed-off-by: Michael Niedermayer
Makefile | 5 +--
configure | 36 --
fftools/ffmpeg.c | 5 +++
fftools/ffplay.c | 4 +++
fftools/ffprobe.c | 4 +++
fftools/opt_common.c | 62
++---
fftools/opt_common.h | 27
libavdevice/Makefile | 1 -
libavdevice/alldevices.c | 1 -
libavdevice/utils.c | 2 +-
libavformat/allformats.c | 32 ++-
libavformat/internal.h| 1 +
libavradio/Makefile | 14 +
libavradio/allradios.c| 65
+++
libavradio/avradio.c | 32 +++
libavradio/avradio.h | 121
libavradio/internal.h | 28 +
libavdevice/sdrindev.c => libavradio/sdrinradio.c | 2 +-
{libavdevice => libavradio}/utils.c | 4 +--
libavradio/version.c | 45
+++
libavradio/version.h | 45
+++
libavradio/version_major.h| 36 ++
libavutil/log.h | 1 +
tools/uncoded_frame.c | 4 +++
24 files changed, 554 insertions(+), 23 deletions(-)
I do not know if changes to the build system can be marged in git master or
if people agree to that at all.
But if this needs to be maintained in its current form, it will cause bugs
and alot of extra work over time
the alternative would be to undo the libavradio thing and rather maintain
sdr as input device and demuxer in the libavradio repository
Of course having the sdr input device and file demuxer in git master would
be the least amount of work
thx
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is a danger to trust the dream we wish for rather than
the science we have, -- Dr. Kenneth Brown
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 v5] avformat/ivfenc: Set the "number of frames" in IVF header
> -Original Message-
> From: ffmpeg-devel On Behalf Of Dai,
> Jianhui J
> Sent: Monday, July 3, 2023 12:26 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of
> frames" in IVF header
>
> Should set "number of frames" to bytes 24-27 of IVF header, not duration.
> It is described by [1], and confirmed by parsing all IVF files in [2].
>
> This commit also updates the md5sum of refs to pass fate-cbs.
>
> [1] Duck IVF - MultimediaWiki
> https://wiki.multimedia.cx/index.php/Duck_IVF
>
> [2] webm/vp8-test-vectors
> https://chromium.googlesource.com/webm/vp8-test-vectors
>
> Signed-off-by: Jianhui Dai
> ---
> libavformat/ivfdec.c| 13 ++---
> libavformat/ivfenc.c| 13 +
> tests/ref/fate/cbs-vp9-vp90-2-03-deltaq | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-06-bilinear | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas | 2 +-
> .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame | 2 +-
> .../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 | 2 +-
> tests/ref/fate/cbs-
> vp9-vp90-2-segmentation-aq-akiyo | 2 +- tests/ref/fate/cbs-vp9-vp90-2-
> segmentation-sf-akiyo | 2 +-
> tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian | 2 +-
> tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 | 2 +-
> tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 | 2 +-
> tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420 | 2 +-
> tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422 | 2 +-
> tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444 | 2 +-
> 15 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c index
> 511f2387ed..141ce4f1be 100644
> --- a/libavformat/ivfdec.c
> +++ b/libavformat/ivfdec.c
> @@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
> st->codecpar->codec_id = ff_codec_get_id(ff_codec_bmp_tags, st-
> >codecpar->codec_tag);
> st->codecpar->width = avio_rl16(s->pb);
> st->codecpar->height = avio_rl16(s->pb);
> -time_base.den = avio_rl32(s->pb);
> -time_base.num = avio_rl32(s->pb);
> -st->duration = avio_rl32(s->pb);
> +time_base.den= avio_rl32(s->pb);
> +time_base.num= avio_rl32(s->pb);
> +st->nb_frames= avio_rl32(s->pb);
> avio_skip(s->pb, 4); // unused
>
> +// Infer duration from nb_frames, in order to be backward compatible with
> +// previous IVF demuxer.
> +// It is popular to configure time_base to 1/frame_rate by IVF muxer,
> that
> +// the duration happens to be the same with nb_frames. See
> +// `https://chromium.googlesource.com/webm/vp8-test-
> vectors/+/refs/heads/main`
> +st->duration = st->nb_frames;
> +
> ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
>
> if (!time_base.den || !time_base.num) { diff --git a/libavformat/ivfenc.c
> b/libavformat/ivfenc.c index 47b4efbcd1..88399099d4 100644
> --- a/libavformat/ivfenc.c
> +++ b/libavformat/ivfenc.c
> @@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
> avio_wl16(pb, par->height);
> avio_wl32(pb, s->streams[0]->time_base.den);
> avio_wl32(pb, s->streams[0]->time_base.num);
> -avio_wl64(pb, 0xULL); // length is overwritten at the
> end of
> muxing
> +avio_wl32(pb, 0x); // "number of frames" is overwritten at the
> end
> of muxing
> +avio_wl32(pb, 0); // unused
>
> return 0;
> }
> @@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
> AVIOContext *pb = s->pb;
> IVFEncContext *ctx = s->priv_data;
>
> -if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
> -(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
> ctx->last_pkt_duration))) {
> +// overwrite the "number of frames"
> +if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
> int64_t end = avio_tell(pb);
>
> avio_seek(pb, 24, SEEK_SET);
> -// overwrite the "length" field (duration)
> -avio_wl32(pb, ctx->last_pkt_duration ?
> - ctx->sum_delta_pts + ctx->last_pkt_duration :
> - ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt -
> 1));
> -avio_wl32(pb, 0); // zero out unused bytes
> +avio_wl32(pb, ctx->frame_cnt);
> avio_seek(pb, end, SEEK_SET);
> }
>
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq b/tests/ref/fate/cbs-vp9-
> vp90-2-03-deltaq
> index db09cfd5e0..f621d7a480 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> +++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
> @@ -1 +1 @@
> -bb630ef560f83951fa6547a664fdb636
> +fe62460fe28202e0666e628afd8602ca
> diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> b/tests/ref/fate/cbs-vp9-
> vp90-2-06-bilinear
> index f579459179..9359e21e40 100644
> --- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
> +++
[FFmpeg-devel] [PATCH v5] avformat/ivfenc: Set the "number of frames" in IVF header
Should set "number of frames" to bytes 24-27 of IVF header, not
duration.
It is described by [1], and confirmed by parsing all IVF files in [2].
This commit also updates the md5sum of refs to pass fate-cbs.
[1] Duck IVF - MultimediaWiki
https://wiki.multimedia.cx/index.php/Duck_IVF
[2] webm/vp8-test-vectors
https://chromium.googlesource.com/webm/vp8-test-vectors
Signed-off-by: Jianhui Dai
---
libavformat/ivfdec.c| 13 ++---
libavformat/ivfenc.c| 13 +
tests/ref/fate/cbs-vp9-vp90-2-03-deltaq | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-06-bilinear | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas | 2 +-
.../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame | 2 +-
.../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian | 2 +-
tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 | 2 +-
tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 | 2 +-
tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420 | 2 +-
tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422 | 2 +-
tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444 | 2 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 511f2387ed..141ce4f1be 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
st->codecpar->codec_id = ff_codec_get_id(ff_codec_bmp_tags,
st->codecpar->codec_tag);
st->codecpar->width = avio_rl16(s->pb);
st->codecpar->height = avio_rl16(s->pb);
-time_base.den = avio_rl32(s->pb);
-time_base.num = avio_rl32(s->pb);
-st->duration = avio_rl32(s->pb);
+time_base.den= avio_rl32(s->pb);
+time_base.num= avio_rl32(s->pb);
+st->nb_frames= avio_rl32(s->pb);
avio_skip(s->pb, 4); // unused
+// Infer duration from nb_frames, in order to be backward compatible with
+// previous IVF demuxer.
+// It is popular to configure time_base to 1/frame_rate by IVF muxer, that
+// the duration happens to be the same with nb_frames. See
+//
`https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/main`
+st->duration = st->nb_frames;
+
ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
if (!time_base.den || !time_base.num) {
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 47b4efbcd1..88399099d4 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
avio_wl32(pb, s->streams[0]->time_base.num);
-avio_wl64(pb, 0xULL); // length is overwritten at the end
of muxing
+avio_wl32(pb, 0x); // "number of frames" is overwritten at the end
of muxing
+avio_wl32(pb, 0); // unused
return 0;
}
@@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
AVIOContext *pb = s->pb;
IVFEncContext *ctx = s->priv_data;
-if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
-(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
ctx->last_pkt_duration))) {
+// overwrite the "number of frames"
+if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
int64_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
-// overwrite the "length" field (duration)
-avio_wl32(pb, ctx->last_pkt_duration ?
- ctx->sum_delta_pts + ctx->last_pkt_duration :
- ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 1));
-avio_wl32(pb, 0); // zero out unused bytes
+avio_wl32(pb, ctx->frame_cnt);
avio_seek(pb, end, SEEK_SET);
}
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
index db09cfd5e0..f621d7a480 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
+++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
@@ -1 +1 @@
-bb630ef560f83951fa6547a664fdb636
+fe62460fe28202e0666e628afd8602ca
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
index f579459179..9359e21e40 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
+++ b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
@@ -1 +1 @@
-2ca9d012c7212e38f5e2727ac66ec6c5
+179e228004c396a301c89f34b6c72f68
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
b/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
index e0b5686d0b..5b21675c76 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
+++ b/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
@@ -1 +1 @@
-78f5e46bfaecbcd62b9126697a0d97b7
+1d1f0768c547461ae2abef57f0aabc24
diff --git
[FFmpeg-devel] [PATCH v4] avformat/ivfenc: Set the "number of frames" in IVF header
Should set "number of frames" to bytes 24-27 of IVF header, not
duration.
It is described by [1], and confirmed by parsing all IVF files in [2].
This commit also updates the md5sum of refs to pass fate-cbs.
[1] Duck IVF - MultimediaWiki
https://wiki.multimedia.cx/index.php/Duck_IVF
[2] webm/vp8-test-vectors
https://chromium.googlesource.com/webm/vp8-test-vectors
Signed-off-by: Jianhui Dai
---
libavformat/ivfdec.c| 13 ++---
libavformat/ivfenc.c| 13 +
tests/ref/fate/cbs-vp9-vp90-2-03-deltaq | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-06-bilinear | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas | 2 +-
.../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame | 2 +-
.../ref/fate/cbs-vp9-vp90-2-10-show-existing-frame2 | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-segmentation-aq-akiyo | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-segmentation-sf-akiyo | 2 +-
tests/ref/fate/cbs-vp9-vp90-2-tiling-pedestrian | 2 +-
tests/ref/fate/cbs-vp9-vp91-2-04-yuv440 | 2 +-
tests/ref/fate/cbs-vp9-vp91-2-04-yuv444 | 2 +-
tests/ref/fate/cbs-vp9-vp92-2-20-10bit-yuv420 | 2 +-
tests/ref/fate/cbs-vp9-vp93-2-20-10bit-yuv422 | 2 +-
tests/ref/fate/cbs-vp9-vp93-2-20-12bit-yuv444 | 2 +-
15 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/libavformat/ivfdec.c b/libavformat/ivfdec.c
index 511f2387ed..8eeaba38ac 100644
--- a/libavformat/ivfdec.c
+++ b/libavformat/ivfdec.c
@@ -51,11 +51,18 @@ static int read_header(AVFormatContext *s)
st->codecpar->codec_id = ff_codec_get_id(ff_codec_bmp_tags,
st->codecpar->codec_tag);
st->codecpar->width = avio_rl16(s->pb);
st->codecpar->height = avio_rl16(s->pb);
-time_base.den = avio_rl32(s->pb);
-time_base.num = avio_rl32(s->pb);
-st->duration = avio_rl32(s->pb);
+time_base.den= avio_rl32(s->pb);
+time_base.num= avio_rl32(s->pb);
+st->nb_frames= avio_rl32(s->pb);
avio_skip(s->pb, 4); // unused
+// Infer duration from nb_frames, in order to be backward compatible with
+// previous IVF demuxer.
+// It is popular to configure time_base to 1/frame_rate by IVF muxer, that
+// the duration is happen to be the same with nb_frames. See
+//
`https://chromium.googlesource.com/webm/vp8-test-vectors/+/refs/heads/main`
+st->duration = st->nb_frames;
+
ffstream(st)->need_parsing = AVSTREAM_PARSE_HEADERS;
if (!time_base.den || !time_base.num) {
diff --git a/libavformat/ivfenc.c b/libavformat/ivfenc.c
index 47b4efbcd1..88399099d4 100644
--- a/libavformat/ivfenc.c
+++ b/libavformat/ivfenc.c
@@ -72,7 +72,8 @@ static int ivf_write_header(AVFormatContext *s)
avio_wl16(pb, par->height);
avio_wl32(pb, s->streams[0]->time_base.den);
avio_wl32(pb, s->streams[0]->time_base.num);
-avio_wl64(pb, 0xULL); // length is overwritten at the end
of muxing
+avio_wl32(pb, 0x); // "number of frames" is overwritten at the end
of muxing
+avio_wl32(pb, 0); // unused
return 0;
}
@@ -99,16 +100,12 @@ static int ivf_write_trailer(AVFormatContext *s)
AVIOContext *pb = s->pb;
IVFEncContext *ctx = s->priv_data;
-if ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
-(ctx->frame_cnt > 1 || (ctx->frame_cnt == 1 &&
ctx->last_pkt_duration))) {
+// overwrite the "number of frames"
+if ((pb->seekable & AVIO_SEEKABLE_NORMAL)) {
int64_t end = avio_tell(pb);
avio_seek(pb, 24, SEEK_SET);
-// overwrite the "length" field (duration)
-avio_wl32(pb, ctx->last_pkt_duration ?
- ctx->sum_delta_pts + ctx->last_pkt_duration :
- ctx->frame_cnt * ctx->sum_delta_pts / (ctx->frame_cnt - 1));
-avio_wl32(pb, 0); // zero out unused bytes
+avio_wl32(pb, ctx->frame_cnt);
avio_seek(pb, end, SEEK_SET);
}
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
index db09cfd5e0..f621d7a480 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
+++ b/tests/ref/fate/cbs-vp9-vp90-2-03-deltaq
@@ -1 +1 @@
-bb630ef560f83951fa6547a664fdb636
+fe62460fe28202e0666e628afd8602ca
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
index f579459179..9359e21e40 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
+++ b/tests/ref/fate/cbs-vp9-vp90-2-06-bilinear
@@ -1 +1 @@
-2ca9d012c7212e38f5e2727ac66ec6c5
+179e228004c396a301c89f34b6c72f68
diff --git a/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
b/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
index e0b5686d0b..5b21675c76 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
+++ b/tests/ref/fate/cbs-vp9-vp90-2-09-lf_deltas
@@ -1 +1 @@
-78f5e46bfaecbcd62b9126697a0d97b7
+1d1f0768c547461ae2abef57f0aabc24
diff --git
Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the "number of frames" in IVF header
> -Original Message- > From: ffmpeg-devel On Behalf Of > Anton Khirnov > Sent: Sunday, July 2, 2023 8:59 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the "number of > frames" in IVF header > > Quoting Ronald S. Bultje (2023-07-02 14:44:42) > > Hi, > > > > On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > > > > > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > > > I see this discussion now... > > > > > > > > I don't think I agree with the above. First of all, IVF has two > > > > fields there (it seems): duration, and n_frames. > > > > > > Got any source for that? I only see one field in > > > https://wiki.multimedia.cx/index.php/Duck_IVF > > > > > > > This somewhat-widely used tool called "ffmpeg" has used it like that > > for the past, say, 10 years. I've heard some projects or companies > > around the world use this tool, and backwards compatibility is supposedly > a thing. > > Yeah yeah very funny. > > You claimed there are two fields. My question was where is this second field > supposed to be. > Thank for all your commentary. Let me update the V4 to set both the `nb_frames` and `duration` in IVF demux. Wish it could be both spec compatible and backward compatible. > -- > 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 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] libswscale/riscv: Fix syntax of vsetvli
Add missing operand which clang complains about but gcc assumes it to be 'm1' if not specifiied. Fixes building with clang | src/libswscale/riscv/rgb2rgb_rvv.S:88:25: error: operand must be e[8|16|32|64|128|256|512|1024],m[1|2|4|8|f2|f4|f8],[ta|tu],[ma|mu] | vsetvli t4, t3, e8, ta, ma | ^ Signed-off-by: Khem Raj --- libswscale/riscv/rgb2rgb_rvv.S | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libswscale/riscv/rgb2rgb_rvv.S b/libswscale/riscv/rgb2rgb_rvv.S index 5626d906eb..bbdfdbebbc 100644 --- a/libswscale/riscv/rgb2rgb_rvv.S +++ b/libswscale/riscv/rgb2rgb_rvv.S @@ -85,7 +85,7 @@ func ff_interleave_bytes_rvv, zve32x mv t3, a3 addia4, a4, -1 2: -vsetvlit4, t3, e8, ta, ma +vsetvlit4, t3, e8, m1, ta, ma subt3, t3, t4 vle8.v v8, (t0) addt0, t4, t0 -- 2.41.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 2/2] avformat/hlsenc: remove openssl/gcrypt random key generation
Marton Balint 于2023年7月3日周一 03:30写道：
>
> av_get_random_seed() should be sufficent and that is used everywhere in the
> codebase for similar cases.
>
> Signed-off-by: Marton Balint
> ---
> configure| 1 -
> libavformat/hlsenc.c | 13 -
> 2 files changed, 14 deletions(-)
>
> diff --git a/configure b/configure
> index 107d533b3e..b331b2e9db 100755
> --- a/configure
> +++ b/configure
> @@ -3507,7 +3507,6 @@ gxf_muxer_select="pcm_rechunk_bsf"
> hds_muxer_select="flv_muxer"
> hls_demuxer_select="adts_header ac3_parser mov_demuxer mpegts_demuxer"
> hls_muxer_select="mov_muxer mpegts_muxer"
> -hls_muxer_suggest="gcrypt openssl"
> image2_alias_pix_demuxer_select="image2_demuxer"
> image2_brender_pix_demuxer_select="image2_demuxer"
> imf_demuxer_deps="libxml2"
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 0b22c71186..f2284e8ea0 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -27,12 +27,6 @@
> #include
> #endif
>
> -#if CONFIG_GCRYPT
> -#include
> -#elif CONFIG_OPENSSL
> -#include
> -#endif
> -
> #include "libavutil/avassert.h"
> #include "libavutil/mathematics.h"
> #include "libavutil/avstring.h"
> @@ -713,13 +707,6 @@ fail:
>
> static void randomize(uint8_t *buf, int len)
> {
> -#if CONFIG_GCRYPT
> -gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> -return;
> -#elif CONFIG_OPENSSL
> -if (RAND_bytes(buf, len))
> -return;
> -#endif
> av_assert0(len % 4 == 0);
> for (int i = 0; i < len; i += 4)
> AV_WB32(buf + i, av_get_random_seed());
> --
> 2.35.3
>
> ___
> 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".
LGTM
Thanks
Steven
___
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] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
Marton Balint 于2023年7月3日周一 03:30写道：
>
> It should be OK to use av_get_random_seed() to generate the key instead of
> using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
> for key generation functionality.
>
> Fixes ticket #10441.
>
> Signed-off-by: Marton Balint
> ---
> libavformat/hlsenc.c | 18 --
> 1 file changed, 8 insertions(+), 10 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 1e0848ce3d..0b22c71186 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -40,6 +40,7 @@
> #include "libavutil/intreadwrite.h"
> #include "libavutil/opt.h"
> #include "libavutil/log.h"
> +#include "libavutil/random_seed.h"
> #include "libavutil/time.h"
> #include "libavutil/time_internal.h"
>
> @@ -710,18 +711,18 @@ fail:
> return ret;
> }
>
> -static int randomize(uint8_t *buf, int len)
> +static void randomize(uint8_t *buf, int len)
> {
> #if CONFIG_GCRYPT
> gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
> -return 0;
> +return;
> #elif CONFIG_OPENSSL
> if (RAND_bytes(buf, len))
> -return 0;
> -#else
> -return AVERROR(ENOSYS);
> +return;
> #endif
> -return AVERROR(EINVAL);
> +av_assert0(len % 4 == 0);
> +for (int i = 0; i < len; i += 4)
> +AV_WB32(buf + i, av_get_random_seed());
> }
>
> static int do_encrypt(AVFormatContext *s, VariantStream *vs)
> @@ -775,10 +776,7 @@ static int do_encrypt(AVFormatContext *s, VariantStream
> *vs)
> if (!*hls->key_string) {
> AVDictionary *options = NULL;
> if (!hls->key) {
> -if ((ret = randomize(key, sizeof(key))) < 0) {
> -av_log(s, AV_LOG_ERROR, "Cannot generate a strong random
> key\n");
> -return ret;
> -}
> +randomize(key, sizeof(key));
> } else {
> memcpy(key, hls->key, sizeof(key));
> }
Hi Marton,
Should remove braces too. I cannot sure how to make it more simpler as
!hls->key ? randomize(key, sizeof(key)) : memcpy(key, hls->key,
sizeof(key)); ?
Thanks
Steven
___
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] export mime_type of data urls
Fix the fact that ffprobe no longer detect m3u8 in a data url correctly.
For example,
ffprobe
data:application/vnd.apple.mpegurl;base64,I0VYVE0zVQojRVhULVgtVkVSU0lPTjozCiNFWFQtWC1UQVJHRVREVVJBVElPTjozMAojRVhUSU5GOjMwLApodHRwczovL2Rvd25sb2FkLnNhbXBsZWxpYi5jb20vbXA0L3NhbXBsZS0zMHMubXA0
This provides the mime_type hls detection requires.
Signed-off-by: David Lou
---
libavformat/data_uri.c | 37 ++---
1 file changed, 30 insertions(+), 7 deletions(-)
diff --git a/libavformat/data_uri.c b/libavformat/data_uri.c
index 28eb2b9e08..fdc1a2eef9 100644
--- a/libavformat/data_uri.c
+++ b/libavformat/data_uri.c
@@ -19,18 +19,24 @@
*/
#include
+
#include "libavutil/avstring.h"
#include "libavutil/avutil.h"
#include "libavutil/base64.h"
+#include "libavutil/opt.h"
+
#include "url.h"
typedef struct {
+const AVClass *class;
const uint8_t *data;
void *tofree;
size_t size;
size_t pos;
+char *mime_type;
} DataContext;
+
static av_cold int data_open(URLContext *h, const char *uri, int flags)
{
DataContext *dc = h->priv_data;
@@ -56,8 +62,10 @@ static av_cold int data_open(URLContext *h, const
char *uri, int flags)
(int)(next - opt), opt);
return AVERROR(EINVAL);
}
-av_log(h, AV_LOG_VERBOSE, "Content-type: %.*s\n",
- (int)(next - opt), opt);
+av_free(dc->mime_type);
+dc->mime_type = av_strndup(opt, (int)(next - opt));
+av_log(h, AV_LOG_VERBOSE, "Content-type: %s\n",
+ dc->mime_type);
} else {
if (!av_strncasecmp(opt, "base64", next - opt)) {
base64 = 1;
@@ -110,10 +118,25 @@ static int data_read(URLContext *h, unsigned char
*buf, int size)
return size;
}
+#define OFFSET(x) offsetof(DataContext, x)
+
+static const AVOption options[] = {
+{ "mime_type", "export the MIME type", OFFSET(mime_type),
AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, AV_OPT_FLAG_EXPORT |
AV_OPT_FLAG_READONLY },
+{ NULL }
+};
+
+static const AVClass data_context_class = {
+.class_name = "data",
+.item_name = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
+
const URLProtocol ff_data_protocol = {
-.name = "data",
-.url_open = data_open,
-.url_close = data_close,
-.url_read = data_read,
-.priv_data_size = sizeof(DataContext),
+.name = "data",
+.url_open = data_open,
+.url_close = data_close,
+.url_read = data_read,
+.priv_data_size = sizeof(DataContext),
+.priv_data_class= _context_class,
};
--
2.41.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] lavfi/tonemap_vaapi: remove HDR metadata
On Vr, 2023-06-30 at 19:51 +0800, Xiang, Haihao wrote: > From: Haihao Xiang > > The HDR metadata should be removed after HDR to SDR conversion, > otherwise the output frame still has HDR side data. > > Signed-off-by: Haihao Xiang > --- > libavfilter/vf_tonemap_vaapi.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/vf_tonemap_vaapi.c b/libavfilter/vf_tonemap_vaapi.c > index cd2f4c2195..52303a8b86 100644 > --- a/libavfilter/vf_tonemap_vaapi.c > +++ b/libavfilter/vf_tonemap_vaapi.c > @@ -309,6 +309,9 @@ static int tonemap_vaapi_filter_frame(AVFilterLink > *inlink, AVFrame *input_frame > av_get_pix_fmt_name(output_frame->format), > output_frame->width, output_frame->height, output_frame->pts); > > + av_frame_remove_side_data(output_frame, > AV_FRAME_DATA_CONTENT_LIGHT_LEVEL); > + av_frame_remove_side_data(output_frame, > AV_FRAME_DATA_MASTERING_DISPLAY_METADATA); > + > return ff_filter_frame(outlink, output_frame); > > fail: Will apply, -Haihao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avutil/dict: add av_dict_pop
Marvin Scholz:
> This new API allows to remove an entry and obtain ownership of the
> key/value that was associated with the removed entry.
> ---
>
> Changes since v1:
> - Clarify documentation about av_free having to be used.
> - Fix fate test to not rely on specific error code value
>
> doc/APIchanges | 4
> libavutil/dict.c | 27 +++
> libavutil/dict.h | 26 ++
> libavutil/tests/dict.c | 38 ++
> libavutil/version.h| 4 ++--
> tests/ref/fate/dict| 12
> 6 files changed, 109 insertions(+), 2 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index f040211f7d..d55821f682 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,10 @@ The last version increases of all libraries were on
> 2023-02-09
>
> API changes, most recent first:
>
> +2023-06-02 - xx - lavu 58.14.100 - dict.h
> + Add av_dict_pop() to remove an entry from a dict
> + and get ownership of the removed key/value.
> +
> 2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
>Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.
>
> diff --git a/libavutil/dict.c b/libavutil/dict.c
> index f673977a98..ac41771994 100644
> --- a/libavutil/dict.c
> +++ b/libavutil/dict.c
> @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char *key,
> int64_t value,
> return av_dict_set(pm, key, valuestr, flags);
> }
>
> +int av_dict_pop(AVDictionary **pm, const char *key,
> +char **out_key, char **out_value, int flags)
> +{
> +AVDictionary *m = *pm;
> +AVDictionaryEntry *entry = NULL;
Why don't you merge this initialization and the assignment below?
> +entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
> +if (!entry)
> +return AVERROR(ENOENT);
> +
> +if (out_key)
> +*out_key = entry->key;
> +else
> +av_free(entry->key);
> +
> +if (out_value)
> +*out_value = entry->value;
> +else
> +av_free(entry->value);
> +
> +*entry = m->elems[--m->count];
> +if (m && !m->count) {
The check for m is completely unnecessary; Coverity will probably
complain about this (because this check implies that m can be NULL, but
then the line above the check would crash).
> +av_freep(>elems);
> +av_freep(pm);
> +}
> +return 0;
> +}
> +
> static int parse_key_value_pair(AVDictionary **pm, const char **buf,
> const char *key_val_sep, const char
> *pairs_sep,
> int flags)
> diff --git a/libavutil/dict.h b/libavutil/dict.h
> index 713c9e361a..31d38dabec 100644
> --- a/libavutil/dict.h
> +++ b/libavutil/dict.h
> @@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key,
> const char *value, int flags
> */
> int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int
> flags);
>
> +/**
> + * Remove the entry with the given key from the dictionary.
> + *
> + * Search for an entry matching @p key and remove it, if found. Optionally
> + * the found key and/or value can be returned using the @p out_key and
> + * @p out_value arguments.
> + *
> + * If more than one entry matches, only one entry is removed and returned
> + * on each call. Which entry is returned first in that case is undefined.
> + *
> + * @param pmPointer to a pointer to a dictionary struct.
> + * @param key Entry key to match.
> + * @param out_key Pointer whose pointee will be set to the matched
> + * entry key. Must be freed using av_dict_free() by
This is wrong: It must be freed using av_free() (or av_freep()); same below.
> + * the caller. May be NULL.
> + * @param out_value Pointer whose pointee will be set to the matched
> + * entry value. Must be freed using av_dict_free() by
> + * the caller. May be NULL.
> + *
> + * @retval 0Success
> + * @retval AVERROR(ENOENT) No item for the given key found
> + * @retval "Other (negative) AVERROR" Other failure
> + */
> +int av_dict_pop(AVDictionary **pm, const char *key,
> +char **out_key, char **out_value, int flags);
It is possible to store multiple entries with the same value in an
AVDictionary. This function is not designed to handle this case, as one
can't tell it which one one wants to pop (IIRC the rest of the API does
not properly support this either, but that is not a reason to add a new
API with this limitation).
Furthermore, while this may be used to avoid a few allocations with the
current implementation, said implementation is not guaranteed to stay
this way.
Finally, are there more intended uses than the one in the second patch?
If so, this could also be simply fixed by strduping the value without
any need for a further API addition.
> +
> /**
> * Parse the
Re: [FFmpeg-devel] [PATCH] avcodec/vlc: auto calculate depth
Paul B Mahol: > Will apply this soon as there are no more comments. My objection still stands. - 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 4/4] fate/cbs: add more VVC tests
Signed-off-by: James Almer --- tests/fate/cbs.mak | 5 + tests/ref/fate/cbs-vvc-APSALF_A_2 | 1 + tests/ref/fate/cbs-vvc-APSLMCS_D_1 | 1 + tests/ref/fate/cbs-vvc-APSMULT_A_4 | 1 + tests/ref/fate/cbs-vvc-DCI_A_3 | 1 + tests/ref/fate/cbs-vvc-OPI_B_3 | 1 + 6 files changed, 10 insertions(+) create mode 100644 tests/ref/fate/cbs-vvc-APSALF_A_2 create mode 100644 tests/ref/fate/cbs-vvc-APSLMCS_D_1 create mode 100644 tests/ref/fate/cbs-vvc-APSMULT_A_4 create mode 100644 tests/ref/fate/cbs-vvc-DCI_A_3 create mode 100644 tests/ref/fate/cbs-vvc-OPI_B_3 diff --git a/tests/fate/cbs.mak b/tests/fate/cbs.mak index 4d8742d99c..802b0351a3 100644 --- a/tests/fate/cbs.mak +++ b/tests/fate/cbs.mak @@ -167,12 +167,17 @@ fate-cbs-hevc: $(FATE_CBS_HEVC-yes) # H.266 read/write FATE_CBS_VVC_SAMPLES =\ +APSALF_A_2.bit\ +APSLMCS_D_1.bit \ +APSMULT_A_4.bit \ AUD_A_3.bit \ BOUNDARY_A_3.bit \ BUMP_A_2.bit \ CodingToolsSets_A_2.bit \ CROP_B_4.bit \ +DCI_A_3.bit \ HRD_A_3.bit \ +OPI_B_3.bit \ PHSH_B_1.bit \ POC_A_1.bit \ PPS_B_1.bit \ diff --git a/tests/ref/fate/cbs-vvc-APSALF_A_2 b/tests/ref/fate/cbs-vvc-APSALF_A_2 new file mode 100644 index 00..eb2fc02a5e --- /dev/null +++ b/tests/ref/fate/cbs-vvc-APSALF_A_2 @@ -0,0 +1 @@ +c981a00e28e51adde1654850935a889d diff --git a/tests/ref/fate/cbs-vvc-APSLMCS_D_1 b/tests/ref/fate/cbs-vvc-APSLMCS_D_1 new file mode 100644 index 00..430dc934b7 --- /dev/null +++ b/tests/ref/fate/cbs-vvc-APSLMCS_D_1 @@ -0,0 +1 @@ +e2e3407885d84e0dee5ec5d51dd4a3a6 diff --git a/tests/ref/fate/cbs-vvc-APSMULT_A_4 b/tests/ref/fate/cbs-vvc-APSMULT_A_4 new file mode 100644 index 00..79f29373b9 --- /dev/null +++ b/tests/ref/fate/cbs-vvc-APSMULT_A_4 @@ -0,0 +1 @@ +66dc3dba5c25bcaab231007bc059c331 diff --git a/tests/ref/fate/cbs-vvc-DCI_A_3 b/tests/ref/fate/cbs-vvc-DCI_A_3 new file mode 100644 index 00..fec635afa5 --- /dev/null +++ b/tests/ref/fate/cbs-vvc-DCI_A_3 @@ -0,0 +1 @@ +2b0eb33eb66078a3454619c5612e7bc2 diff --git a/tests/ref/fate/cbs-vvc-OPI_B_3 b/tests/ref/fate/cbs-vvc-OPI_B_3 new file mode 100644 index 00..99c85165aa --- /dev/null +++ b/tests/ref/fate/cbs-vvc-OPI_B_3 @@ -0,0 +1 @@ +c35066104c7cf9be0e7b9aad5b576256 -- 2.41.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avcodec/cbs_h266: add support for Adaptation parameter set NALU type
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 21 +++
libavcodec/cbs_h266.h | 46 ++
libavcodec/cbs_h266_syntax_template.c | 201 ++
libavcodec/vvc.h | 10 ++
4 files changed, 278 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 95da597427..34c5d1d372 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1116,6 +1116,16 @@ static int cbs_h266_read_nal_unit(CodedBitstreamContext
*ctx,
}
break;
+case VVC_PREFIX_APS_NUT:
+case VVC_SUFFIX_APS_NUT:
+{
+err = cbs_h266_read_aps(ctx, , unit->content,
+unit->type == VVC_PREFIX_APS_NUT);
+
+if (err < 0)
+return err;
+}
+break;
case VVC_PH_NUT:
{
H266RawPH *ph = unit->content;
@@ -1668,6 +1678,15 @@ static int cbs_h266_write_nal_unit(CodedBitstreamContext
*ctx,
}
break;
+case VVC_PREFIX_APS_NUT:
+case VVC_SUFFIX_APS_NUT:
+{
+err = cbs_h266_write_aps(ctx, pbc, unit->content,
+ unit->type == VVC_PREFIX_APS_NUT);
+if (err < 0)
+return err;
+}
+break;
case VVC_PH_NUT:
{
H266RawPH *ph = unit->content;
@@ -2004,6 +2023,8 @@ static const CodedBitstreamUnitTypeDescriptor
cbs_h266_unit_types[] = {
CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS, extension_data.data),
+CBS_UNIT_TYPE_INTERNAL_REF(VVC_PREFIX_APS_NUT, H266RawAPS,
extension_data.data),
+CBS_UNIT_TYPE_INTERNAL_REF(VVC_SUFFIX_APS_NUT, H266RawAPS,
extension_data.data),
CBS_UNIT_TYPE_POD(VVC_PH_NUT , H266RawPH),
CBS_UNIT_TYPE_POD(VVC_AUD_NUT, H266RawAUD),
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 87aa2d849d..d068ffa87a 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -576,6 +576,52 @@ typedef struct H266RawPPS {
uint16_t sub_pic_id_val[VVC_MAX_SLICES];
} H266RawPPS;
+typedef struct H266RawAPS {
+H266RawNALUnitHeader nal_unit_header;
+uint8_t aps_params_type;
+uint8_t aps_adaptation_parameter_set_id;
+uint8_t aps_chroma_present_flag;
+
+uint8_t alf_luma_filter_signal_flag;
+uint8_t alf_chroma_filter_signal_flag;
+uint8_t alf_cc_cb_filter_signal_flag;
+uint8_t alf_cc_cr_filter_signal_flag;
+uint8_t alf_luma_clip_flag;
+uint8_t alf_luma_num_filters_signalled_minus1;
+uint8_t alf_luma_coeff_delta_idx[VVC_NUM_ALF_FILTERS];
+uint8_t alf_luma_coeff_abs[VVC_NUM_ALF_FILTERS][12];
+uint8_t alf_luma_coeff_sign[VVC_NUM_ALF_FILTERS][12];
+uint8_t alf_luma_clip_idx[VVC_NUM_ALF_FILTERS][12];
+uint8_t alf_chroma_clip_flag;
+uint8_t alf_chroma_num_alt_filters_minus1;
+uint8_t alf_chroma_coeff_abs[8][6];
+uint8_t alf_chroma_coeff_sign[8][6];
+uint8_t alf_chroma_clip_idx[8][6];
+uint8_t alf_cc_cb_filters_signalled_minus1;
+uint8_t alf_cc_cb_mapped_coeff_abs[4][7];
+uint8_t alf_cc_cb_coeff_sign[4][7];
+uint8_t alf_cc_cr_filters_signalled_minus1;
+uint8_t alf_cc_cr_mapped_coeff_abs[4][7];
+uint8_t alf_cc_cr_coeff_sign[4][7];
+
+uint8_t scaling_list_copy_mode_flag[28];
+uint8_t scaling_list_pred_mode_flag[28];
+uint8_t scaling_list_pred_id_delta[28];
+int8_t scaling_list_dc_coef[28];
+int8_t scaling_list_delta_coef[28][64];
+
+uint8_t lmcs_min_bin_idx;
+uint8_t lmcs_delta_max_bin_idx;
+uint8_t lmcs_delta_cw_prec_minus1;
+uint16_t lmcs_delta_abs_cw[16];
+uint8_t lmcs_delta_sign_cw_flag[16];
+uint8_t lmcs_delta_abs_crs;
+uint8_t lmcs_delta_sign_crs_flag;
+
+uint8_t aps_extension_flag;
+H266RawExtensionData extension_data;
+} H266RawAPS;
+
typedef struct H266RawAUD {
H266RawNALUnitHeader nal_unit_header;
uint8_t aud_irap_or_gdr_flag;
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 4ea29ec789..61a7237978 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -2183,6 +2183,207 @@ static int FUNC(pps) (CodedBitstreamContext *ctx,
RWContext *rw,
return 0;
}
+static int FUNC(alf_data)(CodedBitstreamContext *ctx, RWContext *rw,
+ H266RawAPS *current)
+{
+int err, j, k;
+
+flag(alf_luma_filter_signal_flag);
+
+if (current->aps_chroma_present_flag) {
+flag(alf_chroma_filter_signal_flag);
+flag(alf_cc_cb_filter_signal_flag);
+flag(alf_cc_cr_filter_signal_flag);
+} else {
+infer(alf_chroma_filter_signal_flag, 0);
+infer(alf_cc_cb_filter_signal_flag, 0);
+infer(alf_cc_cr_filter_signal_flag, 0);
+}
+
+if
[FFmpeg-devel] [PATCH 2/4] avcodec/cbs_h266: add support for Decoding capability information NALU type
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 18 ++
libavcodec/cbs_h266.h | 10 ++
libavcodec/cbs_h266_syntax_template.c | 24
libavcodec/vvc.h | 3 +++
4 files changed, 55 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 8dc9ae471d..95da597427 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1059,6 +1059,14 @@ static int cbs_h266_read_nal_unit(CodedBitstreamContext
*ctx,
return err;
switch (unit->type) {
+case VVC_DCI_NUT:
+{
+err = cbs_h266_read_dci(ctx, , unit->content);
+
+if (err < 0)
+return err;
+}
+break;
case VVC_OPI_NUT:
{
err = cbs_h266_read_opi(ctx, , unit->content);
@@ -1601,6 +1609,15 @@ static int cbs_h266_write_nal_unit(CodedBitstreamContext
*ctx,
int err;
switch (unit->type) {
+case VVC_DCI_NUT:
+{
+H266RawDCI *dci = unit->content;
+
+err = cbs_h266_write_dci(ctx, pbc, dci);
+if (err < 0)
+return err;
+}
+break;
case VVC_OPI_NUT:
{
H266RawOPI *opi = unit->content;
@@ -1982,6 +1999,7 @@ static void cbs_h266_free_sei(void *opaque, uint8_t
*content)
}
static const CodedBitstreamUnitTypeDescriptor cbs_h266_unit_types[] = {
+CBS_UNIT_TYPE_INTERNAL_REF(VVC_DCI_NUT, H266RawDCI, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS, extension_data.data),
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 693d1ca1fd..87aa2d849d 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -241,6 +241,16 @@ typedef struct H266RawOPI {
H266RawExtensionData extension_data;
} H266RawOPI;
+typedef struct H266RawDCI {
+H266RawNALUnitHeader nal_unit_header;
+
+uint8_t dci_reserved_zero_4bits;
+uint8_t dci_num_ptls_minus1;
+H266RawProfileTierLevel dci_profile_tier_level[VVC_MAX_DCI_PTLS];
+uint8_t dci_extension_flag;
+H266RawExtensionData extension_data;
+} H266RawDCI;
+
typedef struct H266RawVPS {
H266RawNALUnitHeader nal_unit_header;
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index d9c8e0afbe..4ea29ec789 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -650,6 +650,30 @@ static int FUNC(opi)(CodedBitstreamContext *ctx, RWContext
*rw,
return 0;
}
+static int FUNC(dci)(CodedBitstreamContext *ctx, RWContext *rw,
+ H266RawDCI *current)
+{
+int err, i;
+
+HEADER("Decoding capability information");
+
+CHECK(FUNC(nal_unit_header)(ctx, rw,
+>nal_unit_header, VVC_DCI_NUT));
+
+ub(4, dci_reserved_zero_4bits);
+ub(4, dci_num_ptls_minus1);
+for (i = 0; i <= current->dci_num_ptls_minus1; i++)
+CHECK(FUNC(profile_tier_level)(ctx, rw,
+ current->dci_profile_tier_level + i, 1,
0));
+
+flag(dci_extension_flag);
+if (current->dci_extension_flag)
+CHECK(FUNC(extension_data)(ctx, rw, >extension_data));
+CHECK(FUNC(rbsp_trailing_bits)(ctx, rw));
+
+return 0;
+}
+
static int FUNC(vps) (CodedBitstreamContext *ctx, RWContext *rw,
H266RawVPS *current)
{
diff --git a/libavcodec/vvc.h b/libavcodec/vvc.h
index 099d2fc2ad..eda1b40eef 100644
--- a/libavcodec/vvc.h
+++ b/libavcodec/vvc.h
@@ -76,6 +76,9 @@ enum {
//7.4.3.3 The value of vps_max_sublayers_minus1 shall be in the range of 0
to 6, inclusive
VVC_MAX_SUBLAYERS = 7,
+//7.3.2.1 dci_num_ptls_minus1 is u(4)
+VVC_MAX_DCI_PTLS = 16,
+
//7.4.3.3 vps_num_ptls_minus1 is u(8)
VVC_MAX_PTLS = 256,
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/cbs_h266: add support for Operating point information NALU type
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 18 ++
libavcodec/cbs_h266.h | 11 +++
libavcodec/cbs_h266_syntax_template.c | 27 +++
3 files changed, 56 insertions(+)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 68ccf6a7eb..8dc9ae471d 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1059,6 +1059,14 @@ static int cbs_h266_read_nal_unit(CodedBitstreamContext
*ctx,
return err;
switch (unit->type) {
+case VVC_OPI_NUT:
+{
+err = cbs_h266_read_opi(ctx, , unit->content);
+
+if (err < 0)
+return err;
+}
+break;
case VVC_VPS_NUT:
{
H266RawVPS *vps = unit->content;
@@ -1593,6 +1601,15 @@ static int cbs_h266_write_nal_unit(CodedBitstreamContext
*ctx,
int err;
switch (unit->type) {
+case VVC_OPI_NUT:
+{
+H266RawOPI *opi = unit->content;
+
+err = cbs_h266_write_opi(ctx, pbc, opi);
+if (err < 0)
+return err;
+}
+break;
case VVC_VPS_NUT:
{
H266RawVPS *vps = unit->content;
@@ -1965,6 +1982,7 @@ static void cbs_h266_free_sei(void *opaque, uint8_t
*content)
}
static const CodedBitstreamUnitTypeDescriptor cbs_h266_unit_types[] = {
+CBS_UNIT_TYPE_INTERNAL_REF(VVC_OPI_NUT, H266RawOPI, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_VPS_NUT, H266RawVPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_SPS_NUT, H266RawSPS, extension_data.data),
CBS_UNIT_TYPE_INTERNAL_REF(VVC_PPS_NUT, H266RawPPS, extension_data.data),
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index e33d08a0f5..693d1ca1fd 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -230,6 +230,17 @@ typedef struct H266RawVUI {
H266RawExtensionData extension_data;
} H266RawVUI;
+typedef struct H266RawOPI {
+H266RawNALUnitHeader nal_unit_header;
+
+uint8_t opi_ols_info_present_flag;
+uint8_t opi_htid_info_present_flag;
+uint16_t opi_ols_idx;
+uint8_t opi_htid_plus1;
+uint8_t opi_extension_flag;
+H266RawExtensionData extension_data;
+} H266RawOPI;
+
typedef struct H266RawVPS {
H266RawNALUnitHeader nal_unit_header;
diff --git a/libavcodec/cbs_h266_syntax_template.c
b/libavcodec/cbs_h266_syntax_template.c
index 957735056f..d9c8e0afbe 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -623,6 +623,33 @@ static int FUNC(ols_timing_hrd_parameters)
(CodedBitstreamContext *ctx,
return 0;
}
+static int FUNC(opi)(CodedBitstreamContext *ctx, RWContext *rw,
+ H266RawOPI *current)
+{
+int err;
+
+HEADER("Operating point information");
+
+CHECK(FUNC(nal_unit_header)(ctx, rw,
+>nal_unit_header, VVC_OPI_NUT));
+
+flag(opi_ols_info_present_flag);
+flag(opi_htid_info_present_flag);
+
+if(current->opi_ols_info_present_flag)
+ue(opi_ols_idx, 0, VVC_MAX_TOTAL_NUM_OLSS - 1);
+
+if(current->opi_htid_info_present_flag)
+ub(3, opi_htid_plus1);
+
+flag(opi_extension_flag);
+if (current->opi_extension_flag)
+CHECK(FUNC(extension_data) (ctx, rw, >extension_data));
+CHECK(FUNC(rbsp_trailing_bits) (ctx, rw));
+
+return 0;
+}
+
static int FUNC(vps) (CodedBitstreamContext *ctx, RWContext *rw,
H266RawVPS *current)
{
--
2.41.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 v6 0/1] avformat: add Software Defined Radio support
On Mon, Jul 03, 2023 at 12:03:10AM +0200, Lynne wrote: > Jul 2, 2023, 23:15 by mich...@niedermayer.cc: > > > On Sun, Jul 02, 2023 at 08:55:40PM +0200, Lynne wrote: > > > >> Jul 2, 2023, 13:01 by mich...@niedermayer.cc: > >> > >> > On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > >> > > >> >> On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: > >> >> > Also as said previously, If there is at least a 2nd developer working > >> >> > on this then we could & should move this to a seperate libraray > >> >> > (libavradio) > >> >> > >> >> Why wait for a 2nd dev? > >> >> > >> > > >> > as libavradio so far has been the only actionable suggestion. > >> > ill move the code to that and next revission or the one after that > >> > will be in libavradio. > >> > > >> > thx > >> > > >> > >> Could you move it to another repository which other developers > >> have access to, like nv-codec-headers? It'll still be an official library > >> of the project, and patches for it should still be sent to this ML, > >> but it would keep the main repo from becoming a monorepo. > >> > > > > Yes > > https://git.ffmpeg.org/libavradio > > g...@git.ffmpeg.org:libavradio > > > > everyone should have acess, but keys a syced from videolan a while ago, so > > if someones is missing, mail me > > > > PS: i found a DAB library that i think can take raw IQ data and return > > AAC frames. With that adding DAB support should be alot more practical > > than a full implementation of all layers of DAB > > > > Thanks. I look forward to see what becomes of it. > Whilst you're at it, could you also make an empty repo > for my streaming protocol/container, with the same access > permissions? It should be named "avstream", without "lib", > as it contains specifications and a reference library, like nut. created: https://git.ffmpeg.org/avstream g...@git.ffmpeg.org:avstream you have power do do non fast forward pushes if need arrises git log mail should go to ffmpeg-cvs...@ffmpeg.org emailmaxlines= 1 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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 v6 0/1] avformat: add Software Defined Radio support
Jul 2, 2023, 23:15 by mich...@niedermayer.cc: > On Sun, Jul 02, 2023 at 08:55:40PM +0200, Lynne wrote: > >> Jul 2, 2023, 13:01 by mich...@niedermayer.cc: >> >> > On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: >> > >> >> On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: >> >> > Also as said previously, If there is at least a 2nd developer working >> >> > on this then we could & should move this to a seperate libraray >> >> > (libavradio) >> >> >> >> Why wait for a 2nd dev? >> >> >> > >> > as libavradio so far has been the only actionable suggestion. >> > ill move the code to that and next revission or the one after that >> > will be in libavradio. >> > >> > thx >> > >> >> Could you move it to another repository which other developers >> have access to, like nv-codec-headers? It'll still be an official library >> of the project, and patches for it should still be sent to this ML, >> but it would keep the main repo from becoming a monorepo. >> > > Yes > https://git.ffmpeg.org/libavradio > g...@git.ffmpeg.org:libavradio > > everyone should have acess, but keys a syced from videolan a while ago, so > if someones is missing, mail me > > PS: i found a DAB library that i think can take raw IQ data and return > AAC frames. With that adding DAB support should be alot more practical > than a full implementation of all layers of DAB > Thanks. I look forward to see what becomes of it. Whilst you're at it, could you also make an empty repo for my streaming protocol/container, with the same access permissions? It should be named "avstream", without "lib", as it contains specifications and a reference library, like nut. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: remove usage of internal AVInputFormat.read_seek field
On Thu, 29 Jun 2023, James Almer wrote:
Signed-off-by: James Almer
---
fftools/ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
LGTM, thanks.
Marton
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 15fd644974..663f61d8b2 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -2639,7 +2639,7 @@ static int stream_component_open(VideoState *is, int
stream_index)
if ((ret = decoder_init(>auddec, avctx, >audioq,
is->continue_read_thread)) < 0)
goto fail;
-if ((is->ic->iformat->flags & (AVFMT_NOBINSEARCH | AVFMT_NOGENSEARCH |
AVFMT_NO_BYTE_SEEK)) && !is->ic->iformat->read_seek) {
+if (is->ic->iformat->flags & AVFMT_NOTIMESTAMPS) {
is->auddec.start_pts = is->audio_st->start_time;
is->auddec.start_pts_tb = is->audio_st->time_base;
}
--
2.41.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 v6 0/1] avformat: add Software Defined Radio support
On Sun, Jul 02, 2023 at 08:55:40PM +0200, Lynne wrote: > Jul 2, 2023, 13:01 by mich...@niedermayer.cc: > > > On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > > > >> On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: > >> > Also as said previously, If there is at least a 2nd developer working > >> > on this then we could & should move this to a seperate libraray > >> > (libavradio) > >> > >> Why wait for a 2nd dev? > >> > > > > as libavradio so far has been the only actionable suggestion. > > ill move the code to that and next revission or the one after that > > will be in libavradio. > > > > thx > > > > Could you move it to another repository which other developers > have access to, like nv-codec-headers? It'll still be an official library > of the project, and patches for it should still be sent to this ML, > but it would keep the main repo from becoming a monorepo. Yes https://git.ffmpeg.org/libavradio g...@git.ffmpeg.org:libavradio everyone should have acess, but keys a syced from videolan a while ago, so if someones is missing, mail me PS: i found a DAB library that i think can take raw IQ data and return AAC frames. With that adding DAB support should be alot more practical than a full implementation of all layers of DAB [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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 05/15] tests/checkasm: Add test for vf_bwdif filter_intra
On Sun, 2 Jul 2023, John Cox wrote:
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 46224bb575..034bbabb4c 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -20,6 +20,7 @@
#include "checkasm.h"
#include "libavcodec/internal.h"
#include "libavfilter/bwdif.h"
+#include "libavutil/mem_internal.h"
#define WIDTH 256
@@ -81,4 +82,40 @@ void checkasm_check_vf_bwdif(void)
BODY(uint16_t, 10);
report("bwdif10");
}
+
+if (check_func(ctx_8.filter_intra, "bwdif8.intra")) {
+LOCAL_ALIGNED_16(uint8_t, cur0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0, [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1, [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+
+declare_func(void, void *dst1, void *cur1, int w, int prefs, int mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+
+randomize_buffers( cur0, cur1, mask, 11*WIDTH);
+memset(dst0, 0xba, WIDTH * 3);
+memset(dst1, 0xba, WIDTH * 3);
+
+call_ref(dst0 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+call_new(dst1 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp( cur0, cur1, WIDTH*11))
+fail();
+
+bench_new(dst1 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+
+report("bwdif8.intra");
+}
It's a bit of a shame that this only tests things for 8 bit, not 10, but I
guess that's better than nothing. The way the current code is set up to
template both variants of the tests isn't very neat either...
// 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 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation
On Sun, 2 Jul 2023, Thomas Mundt wrote:
Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
Add an optional filter_line3 to the available optimisations.
filter_line3 is equivalent to filter_line, memcpy, filter_line
filter_line shares quite a number of loads and some calculations
in
common with its next iteration and testing shows that using
aarch64
neon filter_line3s performance is 30% better than two
filter_lines
and a memcpy.
Signed-off-by: John Cox
---
libavfilter/bwdif.h | 7 +++
libavfilter/vf_bwdif.c | 31 +++
2 files changed, 38 insertions(+)
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index cce99953f3..496cec72ef 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -35,6 +35,9 @@ typedef struct BWDIFContext {
void (*filter_edge)(void *dst, void *prev, void *cur, void
*next,
int w, int prefs, int mrefs, int
prefs2, int mrefs2,
int parity, int clip_max, int spat);
+ void (*filter_line3)(void *dst, int dstride,
+ const void *prev, const void *cur,
const void *next, int prefs,
+ int w, int parity, int clip_max);
} BWDIFContext;
void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
bit_depth);
@@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void
*prev1, void *cur1, void *next1,
int prefs3, int mrefs3, int prefs4,
int mrefs4,
int parity, int clip_max);
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void *
cur1, const void * next1, int s_stride,
+ int w, int parity, int clip_max);
+
#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 26349da1fd..52bc676cf8 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1,
void *prev1, void *cur1, void *next1,
FILTER2()
}
+#define NEXT_LINE()\
+ dst += d_stride; \
+ prev += prefs; \
+ cur += prefs; \
+ next += prefs;
+
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void *
cur1, const void * next1, int s_stride,
+ int w, int parity, int clip_max)
+{
+ const int prefs = s_stride;
+ uint8_t * dst = dst1;
+ const uint8_t * prev = prev1;
+ const uint8_t * cur = cur1;
+ const uint8_t * next = next1;
+
+ ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
(void*)next, w,
+ prefs, -prefs, prefs * 2, - prefs *
2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
clip_max);
+ NEXT_LINE();
+ memcpy(dst, cur, w);
+ NEXT_LINE();
+ ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur,
(void*)next, w,
+ prefs, -prefs, prefs * 2, - prefs *
2, prefs * 3, -prefs * 3, prefs * 4, -prefs * 4, parity,
clip_max);
+}
+
void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void
*cur1, void *next1,
int w, int prefs, int mrefs, int
prefs2, int mrefs2,
int parity, int clip_max, int spat)
@@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext
*ctx, void *arg, int jobnr, int nb_jobs)
refs << 1, -(refs << 1),
td->parity ^ td->tff, clip_max,
(y < 2) || ((y + 3) > td->h) ? 0
: 1);
+ } else if (s->filter_line3 && y + 2 < slice_end &&
y + 6 < td->h) {
+ s->filter_line3(dst,
td->frame->linesize[td->plane],
+ prev, cur, next, linesize,
td->w,
+ td->parity ^ td->tff,
clip_max);
+ y += 2;
} else {
s->filter_line(dst, prev, cur, next, td->w,
refs, -refs, refs << 1, -(refs
<< 1),
Maybe I'm missing something, but doesn't this kick out most of the x86 SIMD
optimization because there is no filter_line3?
It looks to me like it doesn't; it adds a new optional function pointer,
but the reference C function isn't set. So by default (and on x86)
filter_line3 is null, and the old assembly optimized codepaths are used.
Re: [FFmpeg-devel] [PATCH v2 00/15] avfilter/vf_bwdif: Add aarch64 neon functions
On Sun, 2 Jul 2023, John Cox wrote: Also adds a filter_line3 method which on aarch64 neon yields approx 30% speedup over 2xfilter_line and a memcpy Differences from v1: .align 16 corrected to .balign 16 SXTW tolower Mac ABI (hopefully) fixed V register pop/push macroed & prettified John Cox (15): avfilter/vf_bwdif: Add outline for aarch neon functions avfilter/vf_bwdif: Add common macros and consts for aarch64 neon avfilter/vf_bwdif: Export C filter_intra avfilter/vf_bwdif: Add neon for filter_intra tests/checkasm: Add test for vf_bwdif filter_intra avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon avfilter/vf_bwdif: Export C filter_edge avfilter/vf_bwdif: Add neon for filter_edge tests/checkasm: Add test for vf_bwdif filter_edge avfilter/vf_bwdif: Export C filter_line avfilter/vf_bwdif: Add neon for filter_line avfilter/vf_bwdif: Add a filter_line3 method for optimisation avfilter/vf_bwdif: Add neon for filter_line3 tests/checkasm: Add test for vf_bwdif filter_line3 avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines Overall, I'd suggest squashing/reordering the patches like this: - tests/checkasm: Add test for vf_bwdif filter_intra - avfilter/vf_bwdif: Add neon for filter_intra (With the preceding patches squashed. For extra common macros, only add the ones you use in this patch here.) - tests/checkasm: Add test for vf_bwdif filter_edge - avfilter/vf_bwdif: Add neon for filter_edge (with other dependencies squashed) - avfilter/vf_bwdif: Add neon for filter_line - avfilter/vf_bwdif: Add a filter_line3 method for optimisation + checkasm test squashed - avfilter/vf_bwdif: Add neon for filter_line3 // 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 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
On Sun, 2 Jul 2023, John Cox wrote: Add macros for dual scalar half->single multiply and accumulate Add macro for shift, saturate and shorten single to byte Add filter constants Signed-off-by: John Cox --- libavfilter/aarch64/vf_bwdif_neon.S | 53 + 1 file changed, 53 insertions(+) diff --git a/libavfilter/aarch64/vf_bwdif_neon.S b/libavfilter/aarch64/vf_bwdif_neon.S index 639ab22998..c2f5eb1f73 100644 --- a/libavfilter/aarch64/vf_bwdif_neon.S +++ b/libavfilter/aarch64/vf_bwdif_neon.S @@ -23,3 +23,56 @@ #include "libavutil/aarch64/asm.S" +// Space taken on the stack by an int (32-bit) +#ifdef __APPLE__ +.setSP_INT, 4 +#else +.setSP_INT, 8 +#endif Ok I guess this works and doesn't require excessive ifdefs. It can end up brittle though, but I guess this form can be tolerable. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
On Sun, 2 Jul 2023, Martin Storsjö wrote: On Sun, 2 Jul 2023, John Cox wrote: On Sun, 2 Jul 2023 00:35:14 +0300 (EEST), you wrote: On Thu, 29 Jun 2023, John Cox wrote: Add macros for dual scalar half->single multiply and accumulate Add macro for shift, saturate and shorten single to byte Add filter constants Signed-off-by: John Cox --- libavfilter/aarch64/vf_bwdif_neon.S | 46 + 1 file changed, 46 insertions(+) + +.align 16 Note that .align for arm is power of two; this triggers a 2^16 byte alignment here, which certainly isn't intended. Yikes! I'll swap that for a .balign now I've looked that up But in general, the usual way of defining constants is with a const/endconst block, which places them in the right rdata section instead of in the text section. But that then requires you to use a movrel macro for accessing the data, instead of a plain ldr instruction. Yeah - arm has a history of mixing text & const - I went with the simpler code. Is this a deal breaker or can I leave it as is? I wouldn't treat it as a deal breaker as long as it works across all platforms - even if consistency with the code style elsewhere is preferred, but IIRC there may be issues with MS armasm (after passed through gas-preprocessor). IIRC there might be issues with starting out with straight up content without the full setup made by the function/const macros. OTOH I might have fixed that in gas-preprocessor too... Last time around, the patchset failed building in that configuration due ot the out of range alignment, I'll see how it fares now. I'm sorry, but I'd just recommend you to go with the const macros. Your current patch fails because gas-preprocessor, https://github.com/ffmpeg/gas-preprocessor, doesn't support the .balign directive, it only recognizes .align and .p2align. (Extending it to support it would be trivial though.) If I change your code to ".align 4", I get the following warning: \home\martin\code\ffmpeg-msvc-arm64\libavfilter\aarch64\vf_bwdif_neon.o.asm(1011) : warning A4228: Alignment value exceeds AREA alignment; alignment not guaranteed ALIGN 16 Since we haven't started any section, apparently armasm defaults to a section with 4 byte alignment. But anyway, regardless of the alignment, it later fails with this error: \home\martin\code\ffmpeg-msvc-arm64\libavfilter\aarch64\vf_bwdif_neon.o.asm(1051) : error A2504: operand 2: Expected address ldr q0, coeffs So I would request you to just go with the macros we use elsewhere. The gas-preprocessor/armasm setup doesn't support/expect any random assembly, but the disciplined subset we normally write. In most cases, we essentially never write bare directives in the code, but only use the macros from asm.S, which are set up to handle portability across all supported platforms and their toolchains. // 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 11/15] avfilter/vf_bwdif: Add neon for filter_line
On Sun, 2 Jul 2023, John Cox wrote:
On Sun, 2 Jul 2023 00:44:10 +0300 (EEST), you wrote:
On Thu, 29 Jun 2023, John Cox wrote:
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 21 ++
libavfilter/aarch64/vf_bwdif_neon.S | 215
2 files changed, 236 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index e75cf2f204..21e67884ab 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -31,6 +31,26 @@ void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void
*cur1, void *next1,
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max);
+
+
+static void filter_line_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_line_neon(dst1, prev1, cur1, next1,
+ w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+}
static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void *next1,
int w, int prefs, int mrefs, int prefs2, int
mrefs2,
@@ -71,6 +91,7 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_line = filter_line_helper;
s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index a33b235882..675e97d966 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -128,6 +128,221 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+// ===
+//
+// void filter_line(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int prefs3, // [sp, #8]
+// int mrefs3, // [sp, #16]
+// int prefs4, // [sp, #24]
+// int mrefs4, // [sp, #32]
+// int parity, // [sp, #40]
+// int clip_max) // [sp, #48]
+
+function ff_bwdif_filter_line_neon, export=1
+// Sanity check w
+cmp w4, #0
+ble 99f
+
+// Rearrange regs to be the same as line3 for ease of debug!
+mov w10, w4 // w10 = loop count
+mov w9, w6 // w9 = mref
+mov w12, w7 // w12 = pref2
+mov w11, w5 // w11 = pref
+ldr w8, [sp, #0] // w8 = mref2
+ldr w7, [sp, #16] // w7 = mref3
+ldr w6, [sp, #32] // w6 = mref4
+ldr w13, [sp, #8] // w13 = pref3
+ldr w14, [sp, #24] // w14 = pref4
Btw, remember that you can load two arguments from the stack at once with
ldp, e.g. "ldp x8, x13, [sp, #0]". If they're made intptr_t/ptrdiff_t, you
won't have an issue with garbage in the upper 32 bits either.
Fair point - I was indeed worrying about garbage in the upper half (and
this is not performance or size critical code).
Well as long as you actually do refer to the register in the form of w8
instead of x8, it shouldn't matter. Checkasm does try to make sure that
you actually should get garbage in such areas, so if it passes checkasm,
it should be fine.
// Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
Re: [FFmpeg-devel] [PATCH 08/15] avfilter/vf_bwdif: Add neon for filter_edge
On Sun, 2 Jul 2023, John Cox wrote:
On Sun, 2 Jul 2023 00:40:09 +0300 (EEST), you wrote:
On Thu, 29 Jun 2023, John Cox wrote:
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 20
libavfilter/aarch64/vf_bwdif_neon.S | 104
2 files changed, 124 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 3ffaa07ab3..e75cf2f204 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,10 +24,29 @@
#include "libavfilter/bwdif.h"
#include "libavutil/aarch64/cpu.h"
+void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat);
+
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_edge_neon(dst1, prev1, cur1, next1, w0, prefs, mrefs,
prefs2, mrefs2,
+ parity, clip_max, spat);
+
+if (w0 < w)
+ff_bwdif_filter_edge_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2,
+ parity, clip_max, spat);
+}
+
static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max)
{
@@ -52,5 +71,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 6c5d1598f4..a33b235882 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -128,6 +128,110 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+//
+//
+// void ff_bwdif_filter_edge_neon(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int parity, // [sp, #8]
+// int clip_max, // [sp, #16] unused
+// int spat); // [sp, #24]
This doesn't hold for macOS targets (and the checkasm tests fail on that
platform).
On macOS, arguments that aren't passed in registers but on the stack, are
tightly packed. So since parity is 32 bit and mrefs2 also was 32 bit,
parity is available at [sp, #4].
Therefore, it's usually simplest for portability reasons, to pass any
arguments after the first 8, as intptr_t or ptrdiff_t, as that makes them
consistent across platforms.
Not my interface - this is already existing code. What do you suggest I
do?
I'm happy either to change the interface or fix my stack offsets if
there is any clue that lets me detect this ABI. As personal preference
I'd choose the latter.
You can litter the code with "#ifdef __APPLE__", but in general I'd prefer
to not go down that route as it makes the code messier to maintain, and
explicitly requires you to test the code on both system combinations
whenever touching it, compared to just having to test it once if there's a
shared codepath.
We often do change function interfaces to make writing the assembly
simpler; we often change parameters like "int stride" into "ptrdiff_t
stride", to avoid needing explicit sign extension instructions on some
architectures. Changing interfaces for this reason is less common though
(we often don't have many functions that take that many parameters), but
it shouldn't require a lot of changes for other architectures with
existing assembly.
// 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] lavfi/bwdif: remove interpolated sample clipping
On Sun, Jul 2, 2023 at 10:25 PM Lynne wrote: > Jul 2, 2023, 21:38 by one...@gmail.com: > > > On Sun, Jul 2, 2023 at 9:13 PM Lynne wrote: > > > >> Jul 2, 2023, 20:48 by one...@gmail.com: > >> > >> > On Sun, Jul 2, 2023 at 6:57 PM Lynne wrote: > >> > > >> >> Jul 2, 2023, 18:54 by d...@lynne.ee: > >> >> > >> >> > The issue is that clipping the interpolated temporal sample against > >> >> > the spatially predicted sample causes artifacts to appear. > >> >> > > >> >> > Discovered while writing the Vulkan version (where I omitted the > >> >> > same check). > >> >> > > >> >> > The clipping in the code is carried over from yadif. Removing the > >> >> > same code in yadif does not make any difference to the output. > >> >> > I think that the check was simply ill-adapted to the new prediction > >> >> > code and does more harm. > >> >> > > >> >> > I tested replacing the range clip with only an FFMAX, and only an > >> >> > FFMIN, but in both cases, artifacts still appeared. > >> >> > > >> >> > Test sample 1: > >> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample > 2: > >> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv > >> >> > > >> >> > Command line: > >> >> > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v > >> >> rawvideo -y .nut > >> >> > Make sure to disable the assembly. > >> >> > > >> >> > Comparisons: > >> >> > https://files.lynne.ee/bwdif_01_before.png > >> >> > https://files.lynne.ee/bwdif_01_after.png > >> >> > Generated from sample 1 via: > >> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf > >> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png > >> >> > > >> >> > https://files.lynne.ee/bwdif_02_before.png > >> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 > -i > >> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y > >> >> .png > >> >> > > >> >> > >> >> Corrected links for the second sample: > >> >> > >> >> https://files.lynne.ee/bwdif_02_before.png > >> >> https://files.lynne.ee/bwdif_02_after.png > >> >> ffmpeg -ss 00:00:00.417 -i .nut -vf > >> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png > >> >> > >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in > the > >> >> second sample. > >> >> > >> > > >> > Single png images are not way to prove something. > >> > > >> > Please provide videos and not just single file that exhibit this > issue. > >> > (Keep showing same file over and over is not going to help show that > it > >> > helps) > >> > > >> > Also how PSNR/SSIM/VMAF changes before after not just in single sample > >> but > >> > in more samples. > >> > > >> > >> I posted samples and instructions. Enough for a discussion. > >> I'm not posting gigabytes of uncompressed samples. > >> PSNR is irrelevant if there are visible artifacts. > >> > > > > Nope, you havent. > > > > Some strange samples. > > PSNR is relevant as also SSIM and VMAF. > > > > Fair enough, on a 4k60 game recording, with lots of text and movement, > ffmpeg -i game_4k60test.mkv -filter_complex "[0:0] split [t1] [t2] ; [t2] > interlace [t2] ; [t2] bwdif=mode=send_field [t2] ; [t1] [t2] ssim [t3]" > -map "[t3]" -f null - > > Before: > 0.990397 (20.175775) > After: > 0.990417 (20.184970) > Slightly higher, but not really significant. > > PSNR (average): > 32.711758 > vs > 32.704465 > Slightly lower, but not really significant. > > Not very conclusive, I guess I need to test it myself on this sample visually: https://media.xiph.org/video/derf/y4m/west_wind_easy_1080p.y4m > > > Ignoring this does not help project, but just force tyrannic behavior. > > > > Relax, I'm not going to make you write a stablediffusion filter source :) > ___ > 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 v6 0/1] avformat: add Software Defined Radio support
Jul 2, 2023, 21:52 by geo...@nsup.org: > Lynne (12023-07-02): > >> git master is not a playground, but it is certainly a place for developers >> to experiment with ideas they're *seriously* exploring. >> >> Sonic and Snow were experiments. They didn't work out, but nevertheless, >> they made their mark on the status quo of compression research at the time. >> >> FFV1 was an experiment. It worked out, being an IETF standard. >> The native mpeg encoders were experiments. They worked out, and their >> rate control system largely inspired x264's rate control systems. >> The DNN filtering stuff was an experiment. It didn't work out.The native >> Opus encoder was an experiment, and it holds up well against >> libopus, if a bit slow and misguided. >> The AAC encoder was always an experiment. Did it work out? Let's >> find out after the third rewrite :) >> > > Thanks for the history. This is what I called a playground for hackers; > a rose by any other name. > >> As for libavsdr? Time will tell. But it's certainly got a niche to fill, >> as currently, you have to setup large and complex gnuradio filterchains. >> But, I would prefer for it to be in a separate repository. >> > > I have a hard time understanding this preference, for both avradio and > avstream. > > Moving to a separate repository requires you to maintain a separate > build system, separate tests, etc. It also means only enthusiast users > will download and install the library, thus greatly reducing both its > usefulness and its changes of getting off the ground. > Not really, if ffmpeg has a new dependency, distributions are generally eager to use it if it's well packaged and doesn't depend itself on hundreds of other libraries. Moreso if it's an official library. A simple makefile is a few dozen lines, it doesn't have to be automatically generated. And test-wise, FATE wouldn't really be able to cover it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping
Jul 2, 2023, 21:38 by one...@gmail.com: > On Sun, Jul 2, 2023 at 9:13 PM Lynne wrote: > >> Jul 2, 2023, 20:48 by one...@gmail.com: >> >> > On Sun, Jul 2, 2023 at 6:57 PM Lynne wrote: >> > >> >> Jul 2, 2023, 18:54 by d...@lynne.ee: >> >> >> >> > The issue is that clipping the interpolated temporal sample against >> >> > the spatially predicted sample causes artifacts to appear. >> >> > >> >> > Discovered while writing the Vulkan version (where I omitted the >> >> > same check). >> >> > >> >> > The clipping in the code is carried over from yadif. Removing the >> >> > same code in yadif does not make any difference to the output. >> >> > I think that the check was simply ill-adapted to the new prediction >> >> > code and does more harm. >> >> > >> >> > I tested replacing the range clip with only an FFMAX, and only an >> >> > FFMIN, but in both cases, artifacts still appeared. >> >> > >> >> > Test sample 1: >> >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: >> >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv >> >> > >> >> > Command line: >> >> > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v >> >> rawvideo -y .nut >> >> > Make sure to disable the assembly. >> >> > >> >> > Comparisons: >> >> > https://files.lynne.ee/bwdif_01_before.png >> >> > https://files.lynne.ee/bwdif_01_after.png >> >> > Generated from sample 1 via: >> >> > ffmpeg -ss 00:00:00.184 -i .nut -vf >> >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png >> >> > >> >> > https://files.lynne.ee/bwdif_02_before.png >> >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i >> >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y >> >> .png >> >> > >> >> >> >> Corrected links for the second sample: >> >> >> >> https://files.lynne.ee/bwdif_02_before.png >> >> https://files.lynne.ee/bwdif_02_after.png >> >> ffmpeg -ss 00:00:00.417 -i .nut -vf >> >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png >> >> >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the >> >> second sample. >> >> >> > >> > Single png images are not way to prove something. >> > >> > Please provide videos and not just single file that exhibit this issue. >> > (Keep showing same file over and over is not going to help show that it >> > helps) >> > >> > Also how PSNR/SSIM/VMAF changes before after not just in single sample >> but >> > in more samples. >> > >> >> I posted samples and instructions. Enough for a discussion. >> I'm not posting gigabytes of uncompressed samples. >> PSNR is irrelevant if there are visible artifacts. >> > > Nope, you havent. > > Some strange samples. > PSNR is relevant as also SSIM and VMAF. > Fair enough, on a 4k60 game recording, with lots of text and movement, ffmpeg -i game_4k60test.mkv -filter_complex "[0:0] split [t1] [t2] ; [t2] interlace [t2] ; [t2] bwdif=mode=send_field [t2] ; [t1] [t2] ssim [t3]" -map "[t3]" -f null - Before: 0.990397 (20.175775) After: 0.990417 (20.184970) Slightly higher, but not really significant. PSNR (average): 32.711758 vs 32.704465 Slightly lower, but not really significant. > Ignoring this does not help project, but just force tyrannic behavior. > Relax, I'm not going to make you write a stablediffusion filter source :) ___ 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 04/15] avfilter/vf_bwdif: Add neon for filter_intra
On Sun, 2 Jul 2023, John Cox wrote: On Sun, 2 Jul 2023 00:37:35 +0300 (EEST), you wrote: + +uaddl v20.8h, v31.8b, v30.8b +uaddl2 v21.8h, v31.16b, v30.16b + +UMULL4K v2, v3, v4, v5, v20, v21, v0.h[6] + +uaddl v20.8h, v29.8b, v28.8b +uaddl2 v21.8h, v29.16b, v28.16b + +UMLSL4K v2, v3, v4, v5, v20, v21, v0.h[7] + +//dst[0] = av_clip(interpol, 0, clip_max); +SQSHRUNNv2, v2, v3, v4, v5, 13 +str q2, [x0], #16 + +//dst++; +//cur++; +//} + +subsw2, w2, #16 +add x1, x1, #16 For in-order cores, it might be good to update these variables sometime sooner, e.g. before the str instruction. But such scheduling breaks your mapping between neat C code and assembly. I take your point but there is at least 1 instruction between set and use which is normally enough. True, in most cases, it's enough, but sometimes you can save more if there's a stall bubble elsewhere too. I did my benching on a Pi4 and found, to my surprise, that in most cases reordering instructions to interleavse operations made life worse and seeing as Pi4 is my target platform I stopped trying to do that and stuck with code that was easier to read! (Also filter_intra seems to be much more memory b/w limited than code limited on a Pi4.) A Raspberry Pi 4 is Cortex A72, and that one has got out of order execution, so you generally won't be able to notice most of the effects of instruction scheduling. On actual in-order cores, like Cortex A53 (found in e..g the Pi3 and lots of other places), scheduling can have a fairly dramatic effect though. In any case, here it's not a big concern, and one instruction inbetween usually is good enough indeed. // Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
On Sun, 2 Jul 2023, John Cox wrote:
On Sun, 2 Jul 2023 00:35:14 +0300 (EEST), you wrote:
On Thu, 29 Jun 2023, John Cox wrote:
Add macros for dual scalar half->single multiply and accumulate
Add macro for shift, saturate and shorten single to byte
Add filter constants
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_neon.S | 46 +
1 file changed, 46 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 639ab22998..a8f0ed525a 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -23,3 +23,49 @@
#include "libavutil/aarch64/asm.S"
+.macro SQSHRUNN b, s0, s1, s2, s3, n
+sqshrun \s0\().4h, \s0\().4s, #\n - 8
+sqshrun2\s0\().8h, \s1\().4s, #\n - 8
+sqshrun \s1\().4h, \s2\().4s, #\n - 8
+sqshrun2\s1\().8h, \s3\().4s, #\n - 8
+uzp2\b\().16b, \s0\().16b, \s1\().16b
+.endm
+
+.macro SMULL4K a0, a1, a2, a3, s0, s1, k
+smull \a0\().4s, \s0\().4h, \k
+smull2 \a1\().4s, \s0\().8h, \k
+smull \a2\().4s, \s1\().4h, \k
+smull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMULL4K a0, a1, a2, a3, s0, s1, k
+umull \a0\().4s, \s0\().4h, \k
+umull2 \a1\().4s, \s0\().8h, \k
+umull \a2\().4s, \s1\().4h, \k
+umull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLAL4K a0, a1, a2, a3, s0, s1, k
+umlal \a0\().4s, \s0\().4h, \k
+umlal2 \a1\().4s, \s0\().8h, \k
+umlal \a2\().4s, \s1\().4h, \k
+umlal2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLSL4K a0, a1, a2, a3, s0, s1, k
+umlsl \a0\().4s, \s0\().4h, \k
+umlsl2 \a1\().4s, \s0\().8h, \k
+umlsl \a2\().4s, \s1\().4h, \k
+umlsl2 \a3\().4s, \s1\().8h, \k
+.endm
+
+// static const uint16_t coef_lf[2] = { 4309, 213 };
+// static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
+// static const uint16_t coef_sp[2] = { 5077, 981 };
+
+.align 16
Note that .align for arm is power of two; this triggers a 2^16 byte
alignment here, which certainly isn't intended.
Yikes! I'll swap that for a .balign now I've looked that up
But in general, the usual way of defining constants is with a
const/endconst block, which places them in the right rdata section instead
of in the text section. But that then requires you to use a movrel macro
for accessing the data, instead of a plain ldr instruction.
Yeah - arm has a history of mixing text & const - I went with the
simpler code. Is this a deal breaker or can I leave it as is?
I wouldn't treat it as a deal breaker as long as it works across all
platforms - even if consistency with the code style elsewhere is
preferred, but IIRC there may be issues with MS armasm (after passed
through gas-preprocessor). IIRC there might be issues with starting out
with straight up content without the full setup made by the function/const
macros. OTOH I might have fixed that in gas-preprocessor too...
Last time around, the patchset failed building in that configuration due
ot the out of range alignment, I'll see how it fares now.
// 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 v6 0/1] avformat: add Software Defined Radio support
Lynne (12023-07-02): > git master is not a playground, but it is certainly a place for developers > to experiment with ideas they're *seriously* exploring. > > Sonic and Snow were experiments. They didn't work out, but nevertheless, > they made their mark on the status quo of compression research at the time. > > FFV1 was an experiment. It worked out, being an IETF standard. > The native mpeg encoders were experiments. They worked out, and their > rate control system largely inspired x264's rate control systems. > The DNN filtering stuff was an experiment. It didn't work out.The native Opus > encoder was an experiment, and it holds up well against > libopus, if a bit slow and misguided. > The AAC encoder was always an experiment. Did it work out? Let's > find out after the third rewrite :) Thanks for the history. This is what I called a playground for hackers; a rose by any other name. > As for libavsdr? Time will tell. But it's certainly got a niche to fill, > as currently, you have to setup large and complex gnuradio filterchains. > But, I would prefer for it to be in a separate repository. I have a hard time understanding this preference, for both avradio and avstream. Moving to a separate repository requires you to maintain a separate build system, separate tests, etc. It also means only enthusiast users will download and install the library, thus greatly reducing both its usefulness and its changes of getting off the ground. It seems to me like a lose-lose situation. I can understand why people only interested in their short-term revenue stream would object, but people who work on them I do not understand. Can you explain? 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] lavfi/bwdif: remove interpolated sample clipping
On Sun, Jul 2, 2023 at 9:13 PM Lynne wrote: > Jul 2, 2023, 20:48 by one...@gmail.com: > > > On Sun, Jul 2, 2023 at 6:57 PM Lynne wrote: > > > >> Jul 2, 2023, 18:54 by d...@lynne.ee: > >> > >> > The issue is that clipping the interpolated temporal sample against > >> > the spatially predicted sample causes artifacts to appear. > >> > > >> > Discovered while writing the Vulkan version (where I omitted the > >> > same check). > >> > > >> > The clipping in the code is carried over from yadif. Removing the > >> > same code in yadif does not make any difference to the output. > >> > I think that the check was simply ill-adapted to the new prediction > >> > code and does more harm. > >> > > >> > I tested replacing the range clip with only an FFMAX, and only an > >> > FFMIN, but in both cases, artifacts still appeared. > >> > > >> > Test sample 1: > >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: > >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv > >> > > >> > Command line: > >> > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v > >> rawvideo -y .nut > >> > Make sure to disable the assembly. > >> > > >> > Comparisons: > >> > https://files.lynne.ee/bwdif_01_before.png > >> > https://files.lynne.ee/bwdif_01_after.png > >> > Generated from sample 1 via: > >> > ffmpeg -ss 00:00:00.184 -i .nut -vf > >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png > >> > > >> > https://files.lynne.ee/bwdif_02_before.png > >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i > >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y > >> .png > >> > > >> > >> Corrected links for the second sample: > >> > >> https://files.lynne.ee/bwdif_02_before.png > >> https://files.lynne.ee/bwdif_02_after.png > >> ffmpeg -ss 00:00:00.417 -i .nut -vf > >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png > >> > >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the > >> second sample. > >> > > > > Single png images are not way to prove something. > > > > Please provide videos and not just single file that exhibit this issue. > > (Keep showing same file over and over is not going to help show that it > > helps) > > > > Also how PSNR/SSIM/VMAF changes before after not just in single sample > but > > in more samples. > > > > I posted samples and instructions. Enough for a discussion. > I'm not posting gigabytes of uncompressed samples. > PSNR is irrelevant if there are visible artifacts. > Nope, you havent. Some strange samples. PSNR is relevant as also SSIM and VMAF. Ignoring this does not help project, but just force tyrannic behavior. ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avformat/hlsenc: remove openssl/gcrypt random key generation
av_get_random_seed() should be sufficent and that is used everywhere in the
codebase for similar cases.
Signed-off-by: Marton Balint
---
configure| 1 -
libavformat/hlsenc.c | 13 -
2 files changed, 14 deletions(-)
diff --git a/configure b/configure
index 107d533b3e..b331b2e9db 100755
--- a/configure
+++ b/configure
@@ -3507,7 +3507,6 @@ gxf_muxer_select="pcm_rechunk_bsf"
hds_muxer_select="flv_muxer"
hls_demuxer_select="adts_header ac3_parser mov_demuxer mpegts_demuxer"
hls_muxer_select="mov_muxer mpegts_muxer"
-hls_muxer_suggest="gcrypt openssl"
image2_alias_pix_demuxer_select="image2_demuxer"
image2_brender_pix_demuxer_select="image2_demuxer"
imf_demuxer_deps="libxml2"
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 0b22c71186..f2284e8ea0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -27,12 +27,6 @@
#include
#endif
-#if CONFIG_GCRYPT
-#include
-#elif CONFIG_OPENSSL
-#include
-#endif
-
#include "libavutil/avassert.h"
#include "libavutil/mathematics.h"
#include "libavutil/avstring.h"
@@ -713,13 +707,6 @@ fail:
static void randomize(uint8_t *buf, int len)
{
-#if CONFIG_GCRYPT
-gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
-return;
-#elif CONFIG_OPENSSL
-if (RAND_bytes(buf, len))
-return;
-#endif
av_assert0(len % 4 == 0);
for (int i = 0; i < len; i += 4)
AV_WB32(buf + i, av_get_random_seed());
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: fall back to av_get_random_seed() when generating AES128 key
It should be OK to use av_get_random_seed() to generate the key instead of
using openSSL/Gcrypt functions. This removes the hard dependancy of those libs
for key generation functionality.
Fixes ticket #10441.
Signed-off-by: Marton Balint
---
libavformat/hlsenc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 1e0848ce3d..0b22c71186 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -40,6 +40,7 @@
#include "libavutil/intreadwrite.h"
#include "libavutil/opt.h"
#include "libavutil/log.h"
+#include "libavutil/random_seed.h"
#include "libavutil/time.h"
#include "libavutil/time_internal.h"
@@ -710,18 +711,18 @@ fail:
return ret;
}
-static int randomize(uint8_t *buf, int len)
+static void randomize(uint8_t *buf, int len)
{
#if CONFIG_GCRYPT
gcry_randomize(buf, len, GCRY_VERY_STRONG_RANDOM);
-return 0;
+return;
#elif CONFIG_OPENSSL
if (RAND_bytes(buf, len))
-return 0;
-#else
-return AVERROR(ENOSYS);
+return;
#endif
-return AVERROR(EINVAL);
+av_assert0(len % 4 == 0);
+for (int i = 0; i < len; i += 4)
+AV_WB32(buf + i, av_get_random_seed());
}
static int do_encrypt(AVFormatContext *s, VariantStream *vs)
@@ -775,10 +776,7 @@ static int do_encrypt(AVFormatContext *s, VariantStream
*vs)
if (!*hls->key_string) {
AVDictionary *options = NULL;
if (!hls->key) {
-if ((ret = randomize(key, sizeof(key))) < 0) {
-av_log(s, AV_LOG_ERROR, "Cannot generate a strong random
key\n");
-return ret;
-}
+randomize(key, sizeof(key));
} else {
memcpy(key, hls->key, sizeof(key));
}
--
2.35.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add SMC vsynth tests
sön 2023-07-02 klockan 20:57 +0200 skrev Paul B Mahol: > On Sun, Jul 2, 2023 at 6:39 PM Tomas Härdin wrote: > > > sön 2023-07-02 klockan 18:36 +0200 skrev Tomas Härdin: > > > sön 2023-07-02 klockan 12:49 -0300 skrev James Almer: > > > > On 7/2/2023 12:28 PM, Tomas Härdin wrote: > > > > > > > > > > --- > > > > > tests/fate/vcodec.mak | 3 +++ > > > > > tests/ref/vsynth/vsynth1-smc | 4 > > > > > tests/ref/vsynth/vsynth2-smc | 4 > > > > > tests/ref/vsynth/vsynth3-smc | 4 > > > > > tests/ref/vsynth/vsynth_lena-smc | 4 > > > > > 5 files changed, 19 insertions(+) > > > > > create mode 100644 tests/ref/vsynth/vsynth1-smc > > > > > create mode 100644 tests/ref/vsynth/vsynth2-smc > > > > > create mode 100644 tests/ref/vsynth/vsynth3-smc > > > > > create mode 100644 tests/ref/vsynth/vsynth_lena-smc > > > > > > > > > > diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak > > > > > index ef8904613a..833dde86ab 100644 > > > > > --- a/tests/fate/vcodec.mak > > > > > +++ b/tests/fate/vcodec.mak > > > > > @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM) > > > > > += > > > > > rv20 > > > > > fate-vsynth%-rv20: ENCOPTS = -qscale 10 > > > > > fate-vsynth%-rv20: FMT = rm > > > > > > > > > > +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc > > > > > +fate-vsynth%-smc: CODEC = smc > > > > > > > > Missing a FMT = mp4 line (or mov if smc is supported in it). > > > > > > It already says MOV in the call, and mp4 doesn't support SMC > > > > Oh wait the MOV is just for deps I guess, not the actual format > > output. > > Updated patch attached > > > > LGTM > Feel free to push if it passes tests. Passes FATE -> pushed /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping
Jul 2, 2023, 20:48 by one...@gmail.com: > On Sun, Jul 2, 2023 at 6:57 PM Lynne wrote: > >> Jul 2, 2023, 18:54 by d...@lynne.ee: >> >> > The issue is that clipping the interpolated temporal sample against >> > the spatially predicted sample causes artifacts to appear. >> > >> > Discovered while writing the Vulkan version (where I omitted the >> > same check). >> > >> > The clipping in the code is carried over from yadif. Removing the >> > same code in yadif does not make any difference to the output. >> > I think that the check was simply ill-adapted to the new prediction >> > code and does more harm. >> > >> > I tested replacing the range clip with only an FFMAX, and only an >> > FFMIN, but in both cases, artifacts still appeared. >> > >> > Test sample 1: >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv >> > >> > Command line: >> > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v >> rawvideo -y .nut >> > Make sure to disable the assembly. >> > >> > Comparisons: >> > https://files.lynne.ee/bwdif_01_before.png >> > https://files.lynne.ee/bwdif_01_after.png >> > Generated from sample 1 via: >> > ffmpeg -ss 00:00:00.184 -i .nut -vf >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png >> > >> > https://files.lynne.ee/bwdif_02_before.png >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y >> .png >> > >> >> Corrected links for the second sample: >> >> https://files.lynne.ee/bwdif_02_before.png >> https://files.lynne.ee/bwdif_02_after.png >> ffmpeg -ss 00:00:00.417 -i .nut -vf >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the >> second sample. >> > > Single png images are not way to prove something. > > Please provide videos and not just single file that exhibit this issue. > (Keep showing same file over and over is not going to help show that it > helps) > > Also how PSNR/SSIM/VMAF changes before after not just in single sample but > in more samples. > I posted samples and instructions. Enough for a discussion. I'm not posting gigabytes of uncompressed samples. PSNR is irrelevant if there are visible artifacts. ___ 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] lavfi/bwdif: remove interpolated sample clipping
Jul 2, 2023, 20:41 by tmund...@gmail.com: > Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne : > >> Jul 2, 2023, 18:54 by d...@lynne.ee: >> >> > The issue is that clipping the interpolated temporal sample against >> > the spatially predicted sample causes artifacts to appear. >> > >> > Discovered while writing the Vulkan version (where I omitted the >> > same check). >> > >> > The clipping in the code is carried over from yadif. Removing the >> > same code in yadif does not make any difference to the output. >> > I think that the check was simply ill-adapted to the new prediction >> > code and does more harm. >> > >> > I tested replacing the range clip with only an FFMAX, and only an >> > FFMIN, but in both cases, artifacts still appeared. >> > >> > Test sample 1: >> https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: >> https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv >> > >> > Command line: >> > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v >> rawvideo -y .nut >> > Make sure to disable the assembly. >> > >> > Comparisons: >> > https://files.lynne.ee/bwdif_01_before.png >> > https://files.lynne.ee/bwdif_01_after.png >> > Generated from sample 1 via: >> > ffmpeg -ss 00:00:00.184 -i .nut -vf >> crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png >> > >> > https://files.lynne.ee/bwdif_02_before.png >> > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i >> .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y >> .png >> > >> >> Corrected links for the second sample: >> >> https://files.lynne.ee/bwdif_02_before.png >> https://files.lynne.ee/bwdif_02_after.png >> ffmpeg -ss 00:00:00.417 -i .nut -vf >> crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png >> >> I'm sure I hit a newline. The artifacts are a lot more noticeable in the >> second sample. >> > > I developed the bwdif to achieve the best possible balance between speed > and quality of all different image contents from the broadcast point of > view. This includes moving video as well as moving and static graphic > elements. Unfortunately, the improvement of one image content often leads > to the degradation of another. The code you removed fundamentally > stabilizes the static graphic elements. This outweighs the slightly more > frequent artifacts in moving video considering the general purpose of the > filter. > Could you post examples? I've been unable to find any that look worse with the patch. ___ 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 v6 0/1] avformat: add Software Defined Radio support
Jul 2, 2023, 13:01 by mich...@niedermayer.cc: > On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > >> On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: >> > Also as said previously, If there is at least a 2nd developer working >> > on this then we could & should move this to a seperate libraray >> > (libavradio) >> >> Why wait for a 2nd dev? >> > > as libavradio so far has been the only actionable suggestion. > ill move the code to that and next revission or the one after that > will be in libavradio. > > thx > Could you move it to another repository which other developers have access to, like nv-codec-headers? It'll still be an official library of the project, and patches for it should still be sent to this ML, but it would keep the main repo from becoming a monorepo. I'm planning to do the same for libavstream (though, for it, I need it, as I'd like for it to be under the MIT license rather than LGPL). ___ 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 v6 0/1] avformat: add Software Defined Radio support
Jul 2, 2023, 18:08 by geo...@nsup.org: > Jean-Baptiste Kempf (12023-07-02): > >> Absolutely not. >> You are the only one who believes that. >> > > Except for the person who created FFmpeg in the first place. And > probably other people too. > > Most great Libre Software projects are hackers playgrounds first. They > become immensely useful as a byproduct. There is a classical fable to > illustrate the shortsightedness of people who want FFmpeg to be a > Serious OpenSource Project TM, it's called The Goose that Laid the > Golden Eggs, I assume everybody knows how it ends. > git master is not a playground, but it is certainly a place for developers to experiment with ideas they're *seriously* exploring. Sonic and Snow were experiments. They didn't work out, but nevertheless, they made their mark on the status quo of compression research at the time. FFV1 was an experiment. It worked out, being an IETF standard. The native mpeg encoders were experiments. They worked out, and their rate control system largely inspired x264's rate control systems. The DNN filtering stuff was an experiment. It didn't work out.The native Opus encoder was an experiment, and it holds up well against libopus, if a bit slow and misguided. The AAC encoder was always an experiment. Did it work out? Let's find out after the third rewrite :) As for libavsdr? Time will tell. But it's certainly got a niche to fill, as currently, you have to setup large and complex gnuradio filterchains. But, I would prefer for it to be in a separate repository. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add SMC vsynth tests
On Sun, Jul 2, 2023 at 6:39 PM Tomas Härdin wrote: > sön 2023-07-02 klockan 18:36 +0200 skrev Tomas Härdin: > > sön 2023-07-02 klockan 12:49 -0300 skrev James Almer: > > > On 7/2/2023 12:28 PM, Tomas Härdin wrote: > > > > > > > > --- > > > > tests/fate/vcodec.mak| 3 +++ > > > > tests/ref/vsynth/vsynth1-smc | 4 > > > > tests/ref/vsynth/vsynth2-smc | 4 > > > > tests/ref/vsynth/vsynth3-smc | 4 > > > > tests/ref/vsynth/vsynth_lena-smc | 4 > > > > 5 files changed, 19 insertions(+) > > > > create mode 100644 tests/ref/vsynth/vsynth1-smc > > > > create mode 100644 tests/ref/vsynth/vsynth2-smc > > > > create mode 100644 tests/ref/vsynth/vsynth3-smc > > > > create mode 100644 tests/ref/vsynth/vsynth_lena-smc > > > > > > > > diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak > > > > index ef8904613a..833dde86ab 100644 > > > > --- a/tests/fate/vcodec.mak > > > > +++ b/tests/fate/vcodec.mak > > > > @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM)+= > > > > rv20 > > > > fate-vsynth%-rv20: ENCOPTS = -qscale 10 > > > > fate-vsynth%-rv20: FMT = rm > > > > > > > > +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc > > > > +fate-vsynth%-smc:CODEC = smc > > > > > > Missing a FMT = mp4 line (or mov if smc is supported in it). > > > > It already says MOV in the call, and mp4 doesn't support SMC > > Oh wait the MOV is just for deps I guess, not the actual format output. > Updated patch attached > LGTM Feel free to push if it passes tests. > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel 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] lavfi/bwdif: remove interpolated sample clipping
On Sun, Jul 2, 2023 at 6:57 PM Lynne wrote: > Jul 2, 2023, 18:54 by d...@lynne.ee: > > > The issue is that clipping the interpolated temporal sample against > > the spatially predicted sample causes artifacts to appear. > > > > Discovered while writing the Vulkan version (where I omitted the > > same check). > > > > The clipping in the code is carried over from yadif. Removing the > > same code in yadif does not make any difference to the output. > > I think that the check was simply ill-adapted to the new prediction > > code and does more harm. > > > > I tested replacing the range clip with only an FFMAX, and only an > > FFMIN, but in both cases, artifacts still appeared. > > > > Test sample 1: > https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: > https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv > > > > Command line: > > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v > rawvideo -y .nut > > Make sure to disable the assembly. > > > > Comparisons: > > https://files.lynne.ee/bwdif_01_before.png > > https://files.lynne.ee/bwdif_01_after.png > > Generated from sample 1 via: > > ffmpeg -ss 00:00:00.184 -i .nut -vf > crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png > > > > https://files.lynne.ee/bwdif_02_before.png > > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i > .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y > .png > > > > Corrected links for the second sample: > > https://files.lynne.ee/bwdif_02_before.png > https://files.lynne.ee/bwdif_02_after.png > ffmpeg -ss 00:00:00.417 -i .nut -vf > crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png > > I'm sure I hit a newline. The artifacts are a lot more noticeable in the > second sample. > Single png images are not way to prove something. Please provide videos and not just single file that exhibit this issue. (Keep showing same file over and over is not going to help show that it helps) Also how PSNR/SSIM/VMAF changes before after not just in single sample but in more samples. > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avdevice/decklink_enc: use 64bit format string for BMD timebase instead of long long
BMDTimeValue is defined as LONGLONG on Windows, but int64_t on Linux/Mac.
Fixes format string warnings:
libavdevice/decklink_enc.cpp: In function ‘void construct_cc(AVFormatContext*,
decklink_ctx*, AVPacket*, klvanc_line_set_s*)’:
libavdevice/decklink_enc.cpp:424:48: warning: format ‘%lld’ expects argument of
type ‘long long int’, but argument 4 has type ‘BMDTimeValue {aka long int}’
[-Wformat=]
ctx->bmd_tb_num, ctx->bmd_tb_den);
~~~ ^
libavdevice/decklink_enc.cpp:424:48: warning: format ‘%lld’ expects argument of
type ‘long long int’, but argument 5 has type ‘BMDTimeValue {aka long int}’
[-Wformat=]
Signed-off-by: Marton Balint
---
libavdevice/decklink_enc.cpp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 1809f79cac..ffd0ad9250 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -420,7 +420,7 @@ static void construct_cc(AVFormatContext *avctx, struct
decklink_ctx *ctx,
ret = klvanc_set_framerate_EIA_708B(cdp, ctx->bmd_tb_num, ctx->bmd_tb_den);
if (ret) {
-av_log(avctx, AV_LOG_ERROR, "Invalid framerate specified: %lld/%lld\n",
+av_log(avctx, AV_LOG_ERROR, "Invalid framerate specified: %" PRId64
"/%" PRId64 "\n",
ctx->bmd_tb_num, ctx->bmd_tb_den);
klvanc_destroy_eia708_cdp(cdp);
return;
--
2.35.3
___
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] lavfi/bwdif: remove interpolated sample clipping
Am So., 2. Juli 2023 um 18:57 Uhr schrieb Lynne : > Jul 2, 2023, 18:54 by d...@lynne.ee: > > > The issue is that clipping the interpolated temporal sample against > > the spatially predicted sample causes artifacts to appear. > > > > Discovered while writing the Vulkan version (where I omitted the > > same check). > > > > The clipping in the code is carried over from yadif. Removing the > > same code in yadif does not make any difference to the output. > > I think that the check was simply ill-adapted to the new prediction > > code and does more harm. > > > > I tested replacing the range clip with only an FFMAX, and only an > > FFMIN, but in both cases, artifacts still appeared. > > > > Test sample 1: > https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest sample 2: > https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv > > > > Command line: > > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v > rawvideo -y .nut > > Make sure to disable the assembly. > > > > Comparisons: > > https://files.lynne.ee/bwdif_01_before.png > > https://files.lynne.ee/bwdif_01_after.png > > Generated from sample 1 via: > > ffmpeg -ss 00:00:00.184 -i .nut -vf > crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png > > > > https://files.lynne.ee/bwdif_02_before.png > > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i > .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y > .png > > > > Corrected links for the second sample: > > https://files.lynne.ee/bwdif_02_before.png > https://files.lynne.ee/bwdif_02_after.png > ffmpeg -ss 00:00:00.417 -i .nut -vf > crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png > > I'm sure I hit a newline. The artifacts are a lot more noticeable in the > second sample. > I developed the bwdif to achieve the best possible balance between speed and quality of all different image contents from the broadcast point of view. This includes moving video as well as moving and static graphic elements. Unfortunately, the improvement of one image content often leads to the degradation of another. The code you removed fundamentally stabilizes the static graphic elements. This outweighs the slightly more frequent artifacts in moving video considering the general purpose of the filter. For noisy pure motion video content, for example, the w3fdif is better suited, since it does not make if/else decisions and thus does not produce artifacts. Regards, Thomas ___ 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 v6 0/1] avformat: add Software Defined Radio support
On Sun, Jul 02, 2023 at 08:20:03PM +0200, Nicolas George wrote: [...] > It would be 100% legal and within the rules, but stealing nonetheless. > Michael is a thousand times more FFmpeg than you. iam nothing like that and i really dont like how this thread degenerates into increasingly offensive language [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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 v6 0/1] avformat: add Software Defined Radio support
Le 2 juillet 2023 19:01:41 GMT+03:00, Nicolas George a écrit : >Rémi Denis-Courmont (12023-07-02): >> Otherwise it's not offensive and inflammatory. Rather it's insulting and >> defamatory. > >“Bean counter” was derogatory, So you admit to insulting not just me but a whole bunch of other people unprovoked. Duly noted. > but against an attitude like yours, not >against a matter of lower of higher That would mean that you think that (also) you can't do basic arithmetic, which is both extremely dubious and totally inconsistent with your (to put it mildly) self-confident and dismissive attitude. Do you really expect anybody to believe that? >This kind of strategy to assassinate my character is not very honorable, >but not very surprising either. I don't need to remind you that you were the one to attempt "character assassination" (if you want to exaggerate) against me, after I'd dared to make an honest, if blunt, review of your code. The CoC says to presume cluelessness and give the benefit of the doubt, rather than assume ill intent, which is exactly what I did. I see now that the implications that you might have acted out of cluelessness got so under your skin that you had to admit to insulting people instead. I do stand corrected, thank you for that at least. I hope the CC sees this. > >-- > Nicolas George >___ >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 v6 0/1] avformat: add Software Defined Radio support
Jean-Baptiste Kempf (12023-07-02): > Unfortunately, for both questions, I think you are in the minority. > But if you want, we can call an AG vote. You can do so, but be sure to write the question in the way things will happen: “Do you want to continue making FFmpeg a hostile place for hackers who want to have fun, driving them away and sterilizing the process, in the vague hope to gain some more revenue for jb and his friends?” Because you cannot force talented people to work on your schedule. It is sad to see you trying to use the very rules that were put in place to prevent the likes of libav from stealing the project's infrastructure and name recognition in order to steal the project from the people who made it great. It would be 100% legal and within the rules, but stealing nonetheless. Michael is a thousand times more FFmpeg than you. -- Nicolas George ___ 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 v6 0/1] avformat: add Software Defined Radio support
On Sun, 2 Jul 2023, at 18:07, Nicolas George wrote: > Jean-Baptiste Kempf (12023-07-02): >> Absolutely not. >> You are the only one who believes that. > > Except for the person who created FFmpeg in the first place. And probably > other people too. Having talked to Fabrice lately, I didn’t get that this was his vision at all. > illustrate the shortsightedness of people who want FFmpeg to be a > Serious OpenSource Project TM, it's called The Goose that Laid the > Golden Eggs, I assume everybody knows how it ends. I think you are dreaming and I completely disagree with you. But that’s not the question here at all. The question is “what does the majority of the developers want? What does the majority of the users want?” Unfortunately, for both questions, I think you are in the minority. But if you want, we can call an AG vote. jb -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore picture start code in extradata for AVID mpeg2 files
On Tue, 27 Jun 2023, Marton Balint wrote:
AVID IMX MPEG2 files in MOV seems to have extradata like this:
: 0018 4143 4c52 4143 4c52 3030 3031 ACLRACLR0001
0010: 0001
Will apply.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavcodec/mpeg12dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 27c862ffb2..27b45c6fc4 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2522,6 +2522,11 @@ static int decode_chunks(AVCodecContext *avctx, AVFrame
*picture,
}
picture_start_code_seen = 1;
+if (buf == avctx->extradata && avctx->codec_tag ==
AV_RL32("AVmp")) {
+av_log(avctx, AV_LOG_WARNING, "ignoring picture start code in AVmp
extradata\n");
+break;
+}
+
if (s2->width <= 0 || s2->height <= 0) {
av_log(avctx, AV_LOG_ERROR, "Invalid frame dimensions %dx%d.\n",
s2->width, s2->height);
--
2.35.3
___
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 1/7] libavcodec: Preserve AFD side data when going from AVPacket to AVFrame
On Fri, 30 Jun 2023, Devin Heitmueller wrote:
This is needed to ensure that AFD data continues to work when
capturing V210 video with the Decklink libavdevice input.
Will apply.
Thanks,
Marton
Signed-off-by: Devin Heitmueller
---
libavcodec/decode.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index a7c1302..6ee2c85 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1331,6 +1331,7 @@ int ff_decode_frame_props_from_pkt(const AVCodecContext
*avctx,
{ AV_PKT_DATA_MASTERING_DISPLAY_METADATA,
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA },
{ AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
{ AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
+{ AV_PKT_DATA_AFD,AV_FRAME_DATA_AFD },
{ AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE },
{ AV_PKT_DATA_S12M_TIMECODE, AV_FRAME_DATA_S12M_TIMECODE },
{ AV_PKT_DATA_DYNAMIC_HDR10_PLUS,
AV_FRAME_DATA_DYNAMIC_HDR_PLUS },
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation
Am So., 2. Juli 2023 um 14:34 Uhr schrieb John Cox :
> Add an optional filter_line3 to the available optimisations.
>
> filter_line3 is equivalent to filter_line, memcpy, filter_line
>
> filter_line shares quite a number of loads and some calculations in
> common with its next iteration and testing shows that using aarch64
> neon filter_line3s performance is 30% better than two filter_lines
> and a memcpy.
>
> Signed-off-by: John Cox
> ---
> libavfilter/bwdif.h| 7 +++
> libavfilter/vf_bwdif.c | 31 +++
> 2 files changed, 38 insertions(+)
>
> diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
> index cce99953f3..496cec72ef 100644
> --- a/libavfilter/bwdif.h
> +++ b/libavfilter/bwdif.h
> @@ -35,6 +35,9 @@ typedef struct BWDIFContext {
> void (*filter_edge)(void *dst, void *prev, void *cur, void *next,
> int w, int prefs, int mrefs, int prefs2, int
> mrefs2,
> int parity, int clip_max, int spat);
> +void (*filter_line3)(void *dst, int dstride,
> + const void *prev, const void *cur, const void
> *next, int prefs,
> + int w, int parity, int clip_max);
> } BWDIFContext;
>
> void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
> @@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1,
> void *cur1, void *next1,
> int prefs3, int mrefs3, int prefs4, int
> mrefs4,
> int parity, int clip_max);
>
> +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> + const void * prev1, const void * cur1, const
> void * next1, int s_stride,
> + int w, int parity, int clip_max);
> +
> #endif /* AVFILTER_BWDIF_H */
> diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
> index 26349da1fd..52bc676cf8 100644
> --- a/libavfilter/vf_bwdif.c
> +++ b/libavfilter/vf_bwdif.c
> @@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1,
> void *cur1, void *next1,
> FILTER2()
> }
>
> +#define NEXT_LINE()\
> +dst += d_stride; \
> +prev += prefs; \
> +cur += prefs; \
> +next += prefs;
> +
> +void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
> + const void * prev1, const void * cur1, const
> void * next1, int s_stride,
> + int w, int parity, int clip_max)
> +{
> +const int prefs = s_stride;
> +uint8_t * dst = dst1;
> +const uint8_t * prev = prev1;
> +const uint8_t * cur = cur1;
> +const uint8_t * next = next1;
> +
> +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
> + prefs, -prefs, prefs * 2, - prefs * 2, prefs *
> 3, -prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
> +NEXT_LINE();
> +memcpy(dst, cur, w);
> +NEXT_LINE();
> +ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
> + prefs, -prefs, prefs * 2, - prefs * 2, prefs *
> 3, -prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
> +}
> +
> void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void
> *next1,
> int w, int prefs, int mrefs, int prefs2, int
> mrefs2,
> int parity, int clip_max, int spat)
> @@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext *ctx, void
> *arg, int jobnr, int nb_jobs)
> refs << 1, -(refs << 1),
> td->parity ^ td->tff, clip_max,
> (y < 2) || ((y + 3) > td->h) ? 0 : 1);
> +} else if (s->filter_line3 && y + 2 < slice_end && y + 6 <
> td->h) {
> +s->filter_line3(dst, td->frame->linesize[td->plane],
> +prev, cur, next, linesize, td->w,
> +td->parity ^ td->tff, clip_max);
> +y += 2;
> } else {
> s->filter_line(dst, prev, cur, next, td->w,
> refs, -refs, refs << 1, -(refs << 1),
>
Maybe I'm missing something, but doesn't this kick out most of the x86 SIMD
optimization because there is no filter_line3?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] decklink_enc: add support for SMPTE 2038 VANC packet output
On Fri, 30 Jun 2023, Devin Heitmueller wrote:
Support decoding and embedding VANC packets delivered via SMPTE 2038
into the SDI output. We leverage an intermediate queue because
data packets are announced separately from video but we need to embed
the data into the video frame when it is output.
Note that this patch has some additional abstraction for data
streams in general as opposed to just SMPTE 2038 packets. This is
because subsequent patches will introduce support for other
data codecs.
Thanks, will apply with some minor cosmetic change and avdevice micro
version bump.
Regards,
Marton
Thanks to Marton Balint for review/feedback.
Signed-off-by: Devin Heitmueller
---
doc/outdevs.texi| 5 +++
libavdevice/decklink_common.cpp | 16 +++
libavdevice/decklink_common.h | 4 ++
libavdevice/decklink_common_c.h | 1 +
libavdevice/decklink_enc.cpp| 94 -
libavdevice/decklink_enc_c.c| 1 +
6 files changed, 120 insertions(+), 1 deletion(-)
diff --git a/doc/outdevs.texi b/doc/outdevs.texi
index 93391db..f0484bb 100644
--- a/doc/outdevs.texi
+++ b/doc/outdevs.texi
@@ -235,6 +235,11 @@ Enable SMPTE Level A mode on the used output.
Must be @samp{unset}, @samp{true} or @samp{false}.
Defaults to @option{unset}.
+@item vanc_queue_size
+Sets maximum output buffer size in bytes for VANC data. If the buffering
reaches this value,
+outgoing VANC data will be dropped.
+Defaults to @samp{1048576}.
+
@end table
@subsection Examples
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index 5e8d612..6eefb6f1 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -485,6 +485,22 @@ int ff_decklink_packet_queue_get(DecklinkPacketQueue *q,
AVPacket *pkt, int bloc
return ret;
}
+int64_t ff_decklink_packet_queue_peekpts(DecklinkPacketQueue *q)
+{
+PacketListEntry *pkt1;
+int64_t pts = -1;
+
+pthread_mutex_lock(>mutex);
+pkt1 = q->pkt_list.head;
+if (pkt1) {
+pts = pkt1->pkt.pts;
+}
+pthread_mutex_unlock(>mutex);
+
+return pts;
+}
+
+
int ff_decklink_list_devices(AVFormatContext *avctx,
struct AVDeviceInfoList *device_list,
int show_inputs, int show_outputs)
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 53e9983..34ab1b9 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -115,6 +115,9 @@ struct decklink_ctx {
CCFifo cc_fifo; ///< closed captions
+/* Output VANC queue */
+DecklinkPacketQueue vanc_queue;
+
/* Streams present */
int audio;
int video;
@@ -241,5 +244,6 @@ void ff_decklink_packet_queue_end(DecklinkPacketQueue *q);
unsigned long long ff_decklink_packet_queue_size(DecklinkPacketQueue *q);
int ff_decklink_packet_queue_put(DecklinkPacketQueue *q, AVPacket *pkt);
int ff_decklink_packet_queue_get(DecklinkPacketQueue *q, AVPacket *pkt, int
block);
+int64_t ff_decklink_packet_queue_peekpts(DecklinkPacketQueue *q);
#endif /* AVDEVICE_DECKLINK_COMMON_H */
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index 75896ad..9c55d89 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -63,6 +63,7 @@ struct decklink_cctx {
char *format_code;
int raw_format;
int64_t queue_size;
+int64_t vanc_queue_size;
int copyts;
int64_t timestamp_align;
int timing_offset;
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 6906cb0..11e67c4 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -345,6 +345,25 @@ static int decklink_setup_subtitle(AVFormatContext *avctx,
AVStream *st)
return ret;
}
+static int decklink_setup_data(AVFormatContext *avctx, AVStream *st)
+{
+int ret = -1;
+
+switch(st->codecpar->codec_id) {
+#if CONFIG_LIBKLVANC
+case AV_CODEC_ID_SMPTE_2038:
+/* No specific setup required */
+ret = 0;
+break;
+#endif
+default:
+av_log(avctx, AV_LOG_ERROR, "Unsupported data codec specified\n");
+break;
+}
+
+return ret;
+}
+
av_cold int ff_decklink_write_trailer(AVFormatContext *avctx)
{
struct decklink_cctx *cctx = (struct decklink_cctx *)avctx->priv_data;
@@ -370,6 +389,7 @@ av_cold int ff_decklink_write_trailer(AVFormatContext
*avctx)
#if CONFIG_LIBKLVANC
klvanc_context_destroy(ctx->vanc_ctx);
#endif
+ff_decklink_packet_queue_end(>vanc_queue);
ff_ccfifo_uninit(>cc_fifo);
av_freep(>ctx);
@@ -552,6 +572,58 @@ static int decklink_construct_vanc(AVFormatContext *avctx,
struct decklink_ctx *
construct_cc(avctx, ctx, pkt, _lines);
construct_afd(avctx, ctx, pkt, _lines, st);
+/* See if there any pending data packets to process */
+while (ff_decklink_packet_queue_size(>vanc_queue) > 0) {
+AVStream *vanc_st;
+AVPacket vanc_pkt;
+int64_t
Re: [FFmpeg-devel] [PATCH] lavfi/bwdif: remove interpolated sample clipping
Jul 2, 2023, 18:54 by d...@lynne.ee: > The issue is that clipping the interpolated temporal sample against > the spatially predicted sample causes artifacts to appear. > > Discovered while writing the Vulkan version (where I omitted the > same check). > > The clipping in the code is carried over from yadif. Removing the > same code in yadif does not make any difference to the output. > I think that the check was simply ill-adapted to the new prediction > code and does more harm. > > I tested replacing the range clip with only an FFMAX, and only an > FFMIN, but in both cases, artifacts still appeared. > > Test sample 1: https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest > sample 2: https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv > > Command line: > ./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v rawvideo -y > .nut > Make sure to disable the assembly. > > Comparisons: > https://files.lynne.ee/bwdif_01_before.png > https://files.lynne.ee/bwdif_01_after.png > Generated from sample 1 via: > ffmpeg -ss 00:00:00.184 -i .nut -vf > crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png > > https://files.lynne.ee/bwdif_02_before.png > https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i > .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png > Corrected links for the second sample: https://files.lynne.ee/bwdif_02_before.png https://files.lynne.ee/bwdif_02_after.png ffmpeg -ss 00:00:00.417 -i .nut -vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png I'm sure I hit a newline. The artifacts are a lot more noticeable in the second sample. ___ 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 06/15] avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon
Jul 2, 2023, 16:09 by kier...@obe.tv: > On Sun, 2 Jul 2023, 16:02 Lynne wrote: > >> >> Also, keep in mind the final spatial clip at the end should be >> removable. I discovered it makes the filter look quite a lot >> better. Currently, only the Vulkan version does it, but we're >> looking into changing the C/asm versions too, and you're the >> second one to rush into implementing asm for it before we've >> had a chance to discuss it properly. >> > > Didn't Thomas Mundt ask you to provide samples to back up your claim? > I haven't had time to. Until you made me just now. ___ 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] lavfi/bwdif: remove interpolated sample clipping
The issue is that clipping the interpolated temporal sample against
the spatially predicted sample causes artifacts to appear.
Discovered while writing the Vulkan version (where I omitted the
same check).
The clipping in the code is carried over from yadif. Removing the
same code in yadif does not make any difference to the output.
I think that the check was simply ill-adapted to the new prediction
code and does more harm.
I tested replacing the range clip with only an FFMAX, and only an
FFMIN, but in both cases, artifacts still appeared.
Test sample 1: https://files.lynne.ee/testsamples/mbaff_1080i60_idx.mkvTest
sample 2: https://files.lynne.ee/testsamples/mbaff_bdmv_1080i60_8slice.mkv
Command line:
./ffmpeg_g -cpuflags 0 -i -vf bwdif=mode=send_field -c:v rawvideo -y
.nut
Make sure to disable the assembly.
Comparisons:
https://files.lynne.ee/bwdif_01_before.png
https://files.lynne.ee/bwdif_01_after.png
Generated from sample 1 via:
ffmpeg -ss 00:00:00.184 -i .nut -vf
crop=w=420:h=240:x=700:y=300,scale=iw*2:ih*2 -y .png
https://files.lynne.ee/bwdif_02_before.png
https://files.lynne.ee/bwdif_02_after.pngffmpeg -ss 00:00:00.417 -i .nut
-vf crop=w=420:h=240:x=1100:y=200,scale=iw*2:ih*2 -y .png
>From abda922dc040ce7237ad3048f55ab20b03f96a27 Mon Sep 17 00:00:00 2001
From: Lynne
Date: Sun, 2 Jul 2023 18:10:47 +0200
Subject: [PATCH] lavfi/bwdif: remove interpolated sample clipping
The issue is that clipping the interpolated temporal sample against
the spatially predicted sample causes artifacts.
---
libavfilter/vf_bwdif.c | 4
1 file changed, 4 deletions(-)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index e278cf1217..55dec526bf 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -106,10 +106,6 @@ typedef struct ThreadData {
interpol = (c + e) >> 1;
#define FILTER2() \
-if (interpol > d + diff) \
-interpol = d + diff; \
-else if (interpol < d - diff) \
-interpol = d - diff; \
\
dst[0] = av_clip(interpol, 0, clip_max); \
} \
--
2.40.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add SMC vsynth tests
sön 2023-07-02 klockan 18:36 +0200 skrev Tomas Härdin: > sön 2023-07-02 klockan 12:49 -0300 skrev James Almer: > > On 7/2/2023 12:28 PM, Tomas Härdin wrote: > > > > > > --- > > > tests/fate/vcodec.mak | 3 +++ > > > tests/ref/vsynth/vsynth1-smc | 4 > > > tests/ref/vsynth/vsynth2-smc | 4 > > > tests/ref/vsynth/vsynth3-smc | 4 > > > tests/ref/vsynth/vsynth_lena-smc | 4 > > > 5 files changed, 19 insertions(+) > > > create mode 100644 tests/ref/vsynth/vsynth1-smc > > > create mode 100644 tests/ref/vsynth/vsynth2-smc > > > create mode 100644 tests/ref/vsynth/vsynth3-smc > > > create mode 100644 tests/ref/vsynth/vsynth_lena-smc > > > > > > diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak > > > index ef8904613a..833dde86ab 100644 > > > --- a/tests/fate/vcodec.mak > > > +++ b/tests/fate/vcodec.mak > > > @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM) += > > > rv20 > > > fate-vsynth%-rv20: ENCOPTS = -qscale 10 > > > fate-vsynth%-rv20: FMT = rm > > > > > > +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc > > > +fate-vsynth%-smc: CODEC = smc > > > > Missing a FMT = mp4 line (or mov if smc is supported in it). > > It already says MOV in the call, and mp4 doesn't support SMC Oh wait the MOV is just for deps I guess, not the actual format output. Updated patch attached /Tomas From 9cb9b994a162670fbe88fa70fef38c7dd93e19c3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Sun, 2 Jul 2023 16:58:11 +0200 Subject: [PATCH] Add SMC vsynth tests --- tests/fate/vcodec.mak| 4 tests/ref/vsynth/vsynth1-smc | 4 tests/ref/vsynth/vsynth2-smc | 4 tests/ref/vsynth/vsynth3-smc | 4 tests/ref/vsynth/vsynth_lena-smc | 4 5 files changed, 20 insertions(+) create mode 100644 tests/ref/vsynth/vsynth1-smc create mode 100644 tests/ref/vsynth/vsynth2-smc create mode 100644 tests/ref/vsynth/vsynth3-smc create mode 100644 tests/ref/vsynth/vsynth_lena-smc diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index ef8904613a..2839e54de8 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -404,6 +404,10 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM)+= rv20 fate-vsynth%-rv20: ENCOPTS = -qscale 10 fate-vsynth%-rv20: FMT = rm +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc +fate-vsynth%-smc:CODEC = smc +fate-vsynth%-smc:FMT = mov + FATE_VCODEC_SCALE-$(call ENCDEC, SNOW, AVI) += snow snow-hpel fate-vsynth%-snow: ENCOPTS = -qscale 2 -flags +qpel \ -motion_est iter -dia_size 2 \ diff --git a/tests/ref/vsynth/vsynth1-smc b/tests/ref/vsynth/vsynth1-smc new file mode 100644 index 00..09f4bd4ce1 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-smc @@ -0,0 +1,4 @@ +b92226742d745515732a5e7b8a03e7b7 *tests/data/fate/vsynth1-smc.mov +4613320 tests/data/fate/vsynth1-smc.mov +f142ee03bf9f37bb2e1902fe32366bbf *tests/data/fate/vsynth1-smc.out.rawvideo +stddev:8.69 PSNR: 29.34 MAXDIFF: 64 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-smc b/tests/ref/vsynth/vsynth2-smc new file mode 100644 index 00..3ce6478e56 --- /dev/null +++ b/tests/ref/vsynth/vsynth2-smc @@ -0,0 +1,4 @@ +6e97e428fb20e96a5b8fc8a21f427504 *tests/data/fate/vsynth2-smc.mov +3475261 tests/data/fate/vsynth2-smc.mov +df26a524cad8ebf0cf5ba4376c5f115f *tests/data/fate/vsynth2-smc.out.rawvideo +stddev:7.57 PSNR: 30.54 MAXDIFF: 35 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth3-smc b/tests/ref/vsynth/vsynth3-smc new file mode 100644 index 00..ed9efd92e2 --- /dev/null +++ b/tests/ref/vsynth/vsynth3-smc @@ -0,0 +1,4 @@ +e4eb9909095e02577b59004e209ad8ec *tests/data/fate/vsynth3-smc.mov +65521 tests/data/fate/vsynth3-smc.mov +fa6042492a3116c1ae9a32b487caa677 *tests/data/fate/vsynth3-smc.out.rawvideo +stddev:8.88 PSNR: 29.16 MAXDIFF: 51 bytes:86700/86700 diff --git a/tests/ref/vsynth/vsynth_lena-smc b/tests/ref/vsynth/vsynth_lena-smc new file mode 100644 index 00..2f9f5c1e87 --- /dev/null +++ b/tests/ref/vsynth/vsynth_lena-smc @@ -0,0 +1,4 @@ +037fa90a1ac659ff4dca22fb375dc7e1 *tests/data/fate/vsynth_lena-smc.mov +3502732 tests/data/fate/vsynth_lena-smc.mov +db453693ceae6f65c173dd716ee2662e *tests/data/fate/vsynth_lena-smc.out.rawvideo +stddev:8.07 PSNR: 29.99 MAXDIFF: 32 bytes: 7603200/ 7603200 -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add SMC vsynth tests
sön 2023-07-02 klockan 12:49 -0300 skrev James Almer: > On 7/2/2023 12:28 PM, Tomas Härdin wrote: > > > > --- > > tests/fate/vcodec.mak | 3 +++ > > tests/ref/vsynth/vsynth1-smc | 4 > > tests/ref/vsynth/vsynth2-smc | 4 > > tests/ref/vsynth/vsynth3-smc | 4 > > tests/ref/vsynth/vsynth_lena-smc | 4 > > 5 files changed, 19 insertions(+) > > create mode 100644 tests/ref/vsynth/vsynth1-smc > > create mode 100644 tests/ref/vsynth/vsynth2-smc > > create mode 100644 tests/ref/vsynth/vsynth3-smc > > create mode 100644 tests/ref/vsynth/vsynth_lena-smc > > > > diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak > > index ef8904613a..833dde86ab 100644 > > --- a/tests/fate/vcodec.mak > > +++ b/tests/fate/vcodec.mak > > @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM) += rv20 > > fate-vsynth%-rv20: ENCOPTS = -qscale 10 > > fate-vsynth%-rv20: FMT = rm > > > > +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc > > +fate-vsynth%-smc: CODEC = smc > > Missing a FMT = mp4 line (or mov if smc is supported in it). It already says MOV in the call, and mp4 doesn't support SMC /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 v3 1/2] decklink: move queue_size to an argument for ff_decklink_packet_queue_init
On Fri, 30 Jun 2023, Devin Heitmueller wrote:
The existing queue initialization function would always sets it's
maximum queue size to ctx->queue_size. But because we are introducing
more queues we may want the sizes to differ between them.
Move the specification of the queue size into an argument, which can
be passed from the caller.
This patch makes no functional change to the behavior. It is being
made to accommodate Marton Balin's request to split out the queue
size for the new VANC queue being introduced in a later patch.
Signed-off-by: Devin Heitmueller
---
libavdevice/decklink_common.cpp | 4 ++--
libavdevice/decklink_common.h | 2 +-
libavdevice/decklink_dec.cpp| 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index b6cc8d7..5e8d612 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -390,14 +390,14 @@ int ff_decklink_set_format(AVFormatContext *avctx,
decklink_direction_t directio
return ff_decklink_set_format(avctx, 0, 0, 0, 0, AV_FIELD_UNKNOWN,
direction);
}
-void ff_decklink_packet_queue_init(AVFormatContext *avctx, DecklinkPacketQueue
*q)
+void ff_decklink_packet_queue_init(AVFormatContext *avctx, DecklinkPacketQueue
*q, int64_t queue_size)
{
struct decklink_cctx *ctx = (struct decklink_cctx *)avctx->priv_data;
This is now unused.
memset(q, 0, sizeof(DecklinkPacketQueue));
pthread_mutex_init(>mutex, NULL);
pthread_cond_init(>cond, NULL);
q->avctx = avctx;
-q->max_q_size = ctx->queue_size;
+q->max_q_size = queue_size;
}
Will apply with the change above.
Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 0/1] avformat: add Software Defined Radio support
Michael Niedermayer (12023-07-02): > as libavradio so far has been the only actionable suggestion. > ill move the code to that and next revission or the one after that > will be in libavradio. Please only do that if it makes working on the code easier for you. These people will not take concessions and accept your code. They will take every conception you make and demand more, the only thing they will accept is if you stop “wasting” your time on it and go back to work that can increase their revenue stream. Ignore them. -- 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 v6 0/1] avformat: add Software Defined Radio support
Jean-Baptiste Kempf (12023-07-02): > Absolutely not. > You are the only one who believes that. Except for the person who created FFmpeg in the first place. And probably other people too. Most great Libre Software projects are hackers playgrounds first. They become immensely useful as a byproduct. There is a classical fable to illustrate the shortsightedness of people who want FFmpeg to be a Serious OpenSource Project TM, it's called The Goose that Laid the Golden Eggs, I assume everybody knows how it ends. -- Nicolas George ___ 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 v6 0/1] avformat: add Software Defined Radio support
Rémi Denis-Courmont (12023-07-02): > Otherwise it's not offensive and inflammatory. Rather it's insulting and > defamatory. “Bean counter” was derogatory, but against an attitude like yours, not against a matter of lower of higher. This kind of strategy to assassinate my character is not very honorable, but not very surprising either. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add SMC vsynth tests
On 7/2/2023 12:28 PM, Tomas Härdin wrote: --- tests/fate/vcodec.mak| 3 +++ tests/ref/vsynth/vsynth1-smc | 4 tests/ref/vsynth/vsynth2-smc | 4 tests/ref/vsynth/vsynth3-smc | 4 tests/ref/vsynth/vsynth_lena-smc | 4 5 files changed, 19 insertions(+) create mode 100644 tests/ref/vsynth/vsynth1-smc create mode 100644 tests/ref/vsynth/vsynth2-smc create mode 100644 tests/ref/vsynth/vsynth3-smc create mode 100644 tests/ref/vsynth/vsynth_lena-smc diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index ef8904613a..833dde86ab 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM)+= rv20 fate-vsynth%-rv20: ENCOPTS = -qscale 10 fate-vsynth%-rv20: FMT = rm +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc +fate-vsynth%-smc:CODEC = smc Missing a FMT = mp4 line (or mov if smc is supported in it). ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] Add SMC vsynth tests
From 121890df70fe77a646527df71c5a15cb74e24543 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= Date: Sun, 2 Jul 2023 16:58:11 +0200 Subject: [PATCH] Add SMC vsynth tests --- tests/fate/vcodec.mak| 3 +++ tests/ref/vsynth/vsynth1-smc | 4 tests/ref/vsynth/vsynth2-smc | 4 tests/ref/vsynth/vsynth3-smc | 4 tests/ref/vsynth/vsynth_lena-smc | 4 5 files changed, 19 insertions(+) create mode 100644 tests/ref/vsynth/vsynth1-smc create mode 100644 tests/ref/vsynth/vsynth2-smc create mode 100644 tests/ref/vsynth/vsynth3-smc create mode 100644 tests/ref/vsynth/vsynth_lena-smc diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index ef8904613a..833dde86ab 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -404,6 +404,9 @@ FATE_VCODEC-$(call ENCDEC, RV20, RM)+= rv20 fate-vsynth%-rv20: ENCOPTS = -qscale 10 fate-vsynth%-rv20: FMT = rm +FATE_VCODEC_SCALE-$(call ENCDEC, SMC, MOV) += smc +fate-vsynth%-smc:CODEC = smc + FATE_VCODEC_SCALE-$(call ENCDEC, SNOW, AVI) += snow snow-hpel fate-vsynth%-snow: ENCOPTS = -qscale 2 -flags +qpel \ -motion_est iter -dia_size 2 \ diff --git a/tests/ref/vsynth/vsynth1-smc b/tests/ref/vsynth/vsynth1-smc new file mode 100644 index 00..d45b78d72e --- /dev/null +++ b/tests/ref/vsynth/vsynth1-smc @@ -0,0 +1,4 @@ +448fbbcb6a311fce9489081925a1df07 *tests/data/fate/vsynth1-smc.avi +4618210 tests/data/fate/vsynth1-smc.avi +5af05d8c97257442877c45e9ac412a07 *tests/data/fate/vsynth1-smc.out.rawvideo +stddev: 82.04 PSNR: 9.85 MAXDIFF: 239 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth2-smc b/tests/ref/vsynth/vsynth2-smc new file mode 100644 index 00..58d5ceb671 --- /dev/null +++ b/tests/ref/vsynth/vsynth2-smc @@ -0,0 +1,4 @@ +0deb655a3f142cc128d6bd06b93a4553 *tests/data/fate/vsynth2-smc.avi +3480126 tests/data/fate/vsynth2-smc.avi +6d7dc705f762a7ee1f8139cdc99feba6 *tests/data/fate/vsynth2-smc.out.rawvideo +stddev: 103.76 PSNR: 7.81 MAXDIFF: 228 bytes: 7603200/ 7603200 diff --git a/tests/ref/vsynth/vsynth3-smc b/tests/ref/vsynth/vsynth3-smc new file mode 100644 index 00..cec8995f9e --- /dev/null +++ b/tests/ref/vsynth/vsynth3-smc @@ -0,0 +1,4 @@ +bcb01dfa0c66294bf8b367b441dca966 *tests/data/fate/vsynth3-smc.avi +70446 tests/data/fate/vsynth3-smc.avi +0293080027cfea20a539a9947c335ca3 *tests/data/fate/vsynth3-smc.out.rawvideo +stddev: 62.19 PSNR: 12.26 MAXDIFF: 231 bytes:86700/86700 diff --git a/tests/ref/vsynth/vsynth_lena-smc b/tests/ref/vsynth/vsynth_lena-smc new file mode 100644 index 00..647aedf34d --- /dev/null +++ b/tests/ref/vsynth/vsynth_lena-smc @@ -0,0 +1,4 @@ +ce75739815134bdfc68fce38d8ea95e8 *tests/data/fate/vsynth_lena-smc.avi +3507608 tests/data/fate/vsynth_lena-smc.avi +7c756aa5cc4e7983259e830d2024050c *tests/data/fate/vsynth_lena-smc.out.rawvideo +stddev: 77.95 PSNR: 10.29 MAXDIFF: 221 bytes: 7603200/ 7603200 -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Sun, Jul 2, 2023 at 8:59 AM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2023-07-02 14:44:42) > > Hi, > > > > On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > > > > > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > > > I see this discussion now... > > > > > > > > I don't think I agree with the above. First of all, IVF has two > fields > > > > there (it seems): duration, and n_frames. > > > > > > Got any source for that? I only see one field in > > > https://wiki.multimedia.cx/index.php/Duck_IVF > > > > > > > This somewhat-widely used tool called "ffmpeg" has used it like that for > > the past, say, 10 years. I've heard some projects or companies around the > > world use this tool, and backwards compatibility is supposedly a thing. > > Yeah yeah very funny. > > You claimed there are two fields. My question was where is this second > field supposed to be. > I'm not joking. It's literally introduced by ffmpeg. If you look at the originators of the ivf format, they write a 32bit field at header_offset+24 called nb_frames, and an "unused" entry at header_offset+28. FFmpeg adds nothing at header_offset+24 and duration at header_offset+28. We essentially added that field, in the same way that we extended the y4m format, or support unofficial B-frames in AVI etc. You may not like it, neither do I, but these files exist, and I don't think we should break them. 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".
Re: [FFmpeg-devel] [PATCH v2 06/15] avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon
On Sun, 2 Jul 2023, 16:02 Lynne wrote: > > Also, keep in mind the final spatial clip at the end should be > removable. I discovered it makes the filter look quite a lot > better. Currently, only the Vulkan version does it, but we're > looking into changing the C/asm versions too, and you're the > second one to rush into implementing asm for it before we've > had a chance to discuss it properly. > Didn't Thomas Mundt ask you to provide samples to back up your claim? Kieran > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 06/15] avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon
Jul 2, 2023, 14:34 by j...@kynesim.co.uk: > Signed-off-by: John Cox > --- > libavfilter/aarch64/vf_bwdif_neon.S | 73 + > 1 file changed, 73 insertions(+) > > diff --git a/libavfilter/aarch64/vf_bwdif_neon.S > b/libavfilter/aarch64/vf_bwdif_neon.S > index 6a614f8d6e..48dc7bcd9d 100644 > --- a/libavfilter/aarch64/vf_bwdif_neon.S > +++ b/libavfilter/aarch64/vf_bwdif_neon.S > @@ -66,6 +66,79 @@ > umlsl2 \a3\().4s, \s1\().8h, \k > .endm > > +// int b = m2s1 - m1; > +// int f = p2s1 - p1; > +// int dc = c0s1 - m1; > +// int de = c0s1 - p1; > +// int sp_max = FFMIN(p1 - c0s1, m1 - c0s1); > +// sp_max = FFMIN(sp_max, FFMAX(-b,-f)); > +// int sp_min = FFMIN(c0s1 - p1, c0s1 - m1); > +// sp_min = FFMIN(sp_min, FFMAX(b,f)); > +// diff = diff == 0 ? 0 : FFMAX3(diff, sp_min, sp_max); > +.macro SPAT_CHECK diff, m2s1, m1, c0s1, p1, p2s1, t0, t1, t2, t3 > +uqsub \t0\().16b, \p1\().16b, \c0s1\().16b > +uqsub \t2\().16b, \m1\().16b, \c0s1\().16b > +umin\t2\().16b, \t0\().16b, \t2\().16b > + > +uqsub \t1\().16b, \m1\().16b, \m2s1\().16b > +uqsub \t3\().16b, \p1\().16b, \p2s1\().16b > +umax\t3\().16b, \t3\().16b, \t1\().16b > +umin\t3\().16b, \t3\().16b, \t2\().16b > + > +uqsub \t0\().16b, \c0s1\().16b, \p1\().16b > +uqsub \t2\().16b, \c0s1\().16b, \m1\().16b > +umin\t2\().16b, \t0\().16b, \t2\().16b > + > +uqsub \t1\().16b, \m2s1\().16b, \m1\().16b > +uqsub \t0\().16b, \p2s1\().16b, \p1\().16b > +umax\t0\().16b, \t0\().16b, \t1\().16b > +umin\t2\().16b, \t2\().16b, \t0\().16b > + > +cmeq\t1\().16b, \diff\().16b, #0 > +umax\diff\().16b, \diff\().16b, \t3\().16b > +umax\diff\().16b, \diff\().16b, \t2\().16b > +bic \diff\().16b, \diff\().16b, \t1\().16b > +.endm > + > +// i0 = s0; > +// if (i0 > d0 + diff0) > +// i0 = d0 + diff0; > +// else if (i0 < d0 - diff0) > +// i0 = d0 - diff0; > +// > +// i0 = s0 is safe > +.macro DIFF_CLIP i0, s0, d0, diff, t0, t1 > +uqadd \t0\().16b, \d0\().16b, \diff\().16b > +uqsub \t1\().16b, \d0\().16b, \diff\().16b > +umin\i0\().16b, \s0\().16b, \t0\().16b > +umax\i0\().16b, \i0\().16b, \t1\().16b > +.endm > + > +// i0 = FFABS(m1 - p1) > td0 ? i1 : i2; > +// DIFF_CLIP > +// > +// i0 = i1 is safe > +.macro INTERPOL i0, i1, i2, m1, d0, p1, td0, diff, t0, t1, t2 > +uabd\t0\().16b, \m1\().16b, \p1\().16b > +cmhi\t0\().16b, \t0\().16b, \td0\().16b > +bsl \t0\().16b, \i1\().16b, \i2\().16b > +DIFF_CLIP \i0, \t0, \d0, \diff, \t1, \t2 > +.endm > + > +.macro PUSH_VREGS > +stp d8, d9, [sp, #-64]! > +stp d10, d11, [sp, #16] > +stp d12, d13, [sp, #32] > +stp d14, d15, [sp, #48] > +.endm > + > +.macro POP_VREGS > +ldp d14, d15, [sp, #48] > +ldp d12, d13, [sp, #32] > +ldp d10, d11, [sp, #16] > +ldp d8, d9, [sp], #64 > +.endm > Could you squash? Adding empty files and then commit by commit filling them up is pointless and makes it harder to review. Just export what you need in one commit, and add everything else in another. Also, keep in mind the final spatial clip at the end should be removable. I discovered it makes the filter look quite a lot better. Currently, only the Vulkan version does it, but we're looking into changing the C/asm versions too, and you're the second one to rush into implementing asm for it before we've had a chance to discuss it properly. ___ 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 v6 0/1] avformat: add Software Defined Radio support
Hi, Le 2 juillet 2023 13:08:54 GMT+03:00, Paul B Mahol a écrit : >On Sun, Jul 2, 2023 at 11:40 AM Nicolas George wrote: > >> Michael Niedermayer (12023-06-30): >> > And if we could put it in git master then people could work together to >> > build the libavradio out of it as we all want. >> > >> > Such collaboration is kind of one of the reasons of having a "git master" >> >> I want you to continue writing your great code where it is the easiest >> to install and enjoy for users and to contribute for others. Right now, >> at the very beginning of the project, and since you are very familiar >> with FFmpeg, a part of FFmpeg is the right place. >> >> The bean counters who tell you otherwise are actually not very good at >> counting beans, when it is not their own. >> > >I find this way of writing very offensive and inflammatory. Judging by his email domain name, he is/was involved with possibly the most prestigious and selective grad/post-grad institution in the field of mathematics in France. He probably doesn't understand the low level of arithmetic expertise is needed of actual accountants, as opposed to FFmpeg developers. From his standpoint, they're just both much lower than his. Otherwise it's not offensive and inflammatory. Rather it's insulting and defamatory. >Great code in FFmpeg? Where is that code hiding. > > >> >> Regards, >> >> -- >> Nicolas George >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> To unsubscribe, visit link above, or email >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". >> >___ >ffmpeg-devel mailing list >ffmpeg-devel@ffmpeg.org >https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >To unsubscribe, visit link above, or email >ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/cbs_h266: don't infer derived values
The macro is meant for coded values only. Signed-off-by: James Almer --- libavcodec/cbs_h266_syntax_template.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index ae44565a54..957735056f 100644 --- a/libavcodec/cbs_h266_syntax_template.c +++ b/libavcodec/cbs_h266_syntax_template.c @@ -2015,9 +2015,9 @@ static int FUNC(pps) (CodedBitstreamContext *ctx, RWContext *rw, infer(pps_tile_column_width_minus1[0], pic_width_in_ctbs_y - 1); infer(pps_num_exp_tile_rows_minus1, 0); infer(pps_tile_row_height_minus1[0], pic_height_in_ctbs_y - 1); -infer(num_tile_columns, 1); -infer(num_tile_rows, 1); -infer(num_tiles_in_pic, 1); +current->num_tile_columns = 1; +current->num_tile_rows = 1; +current->num_tiles_in_pic = 1; } flag(pps_cabac_init_present_flag); -- 2.41.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 v2 1/2] avcodec/cbs_h2645: fix parsing and storing Picture Header references in the context
On 7/1/2023 10:06 PM, Nuo Mi wrote:
On Sun, Jul 2, 2023 at 7:32 AM James Almer wrote:
On 7/1/2023 8:51 AM, Nuo Mi wrote:
On Fri, Jun 30, 2023 at 6:45 AM James Almer wrote:
Signed-off-by: James Almer
---
libavcodec/cbs_h2645.c| 35 ---
libavcodec/cbs_h266.h | 17 +++--
libavcodec/cbs_h266_syntax_template.c | 17 ++---
libavcodec/h266_metadata_bsf.c| 13 +-
libavcodec/vvc_parser.c | 10
5 files changed, 50 insertions(+), 42 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index cdd7901518..68ccf6a7eb 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -525,12 +525,6 @@ static int
cbs_h2645_split_fragment(CodedBitstreamContext *ctx,
if (frag->data_size == 0)
return 0;
-if (codec_id == AV_CODEC_ID_VVC) {
-//we deactive picture header here to avoid reuse previous au's
ph.
-CodedBitstreamH266Context *h266 = ctx->priv_data;
-h266->priv.ph = NULL;
-}
-
if (header && frag->data[0] && codec_id == AV_CODEC_ID_H264) {
// AVCC header.
size_t size, start, end;
@@ -793,19 +787,20 @@ cbs_h266_replace_ps(6, SPS, sps,
sps_seq_parameter_set_id)
cbs_h266_replace_ps(6, PPS, pps, pps_pic_parameter_set_id)
static int cbs_h266_replace_ph(CodedBitstreamContext *ctx,
- CodedBitstreamUnit *unit)
+ CodedBitstreamUnit *unit,
+ H266RawPictureHeader *ph)
{
CodedBitstreamH266Context *h266 = ctx->priv_data;
int err;
-h266->priv.ph = NULL;
err = ff_cbs_make_unit_refcounted(ctx, unit);
if (err < 0)
return err;
-err = av_buffer_replace(>priv.ph_ref, unit->content_ref);
+av_assert0(unit->content_ref);
+err = av_buffer_replace(>ph_ref, unit->content_ref);
if (err < 0)
return err;
-h266->priv.ph = (H266RawPH*)h266->priv.ph_ref->data;
+h266->ph = ph;
return 0;
}
@@ -,7 +1106,7 @@ static int
cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
err = cbs_h266_read_ph(ctx, , ph);
if (err < 0)
return err;
-err = cbs_h266_replace_ph(ctx, unit);
+err = cbs_h266_replace_ph(ctx, unit,
>ph_picture_header);
if (err < 0)
return err;
}
@@ -1139,6 +1134,12 @@ static int
cbs_h266_read_nal_unit(CodedBitstreamContext *ctx,
pos = get_bits_count();
len = unit->data_size;
+if (slice->header.sh_picture_header_in_slice_header_flag) {
+err = cbs_h266_replace_ph(ctx, unit,
>header.sh_picture_header);
+if (err < 0)
+return err;
+}
+
slice->data_size = len - pos / 8;
slice->data_ref = av_buffer_ref(unit->data_ref);
if (!slice->data_ref)
@@ -1640,7 +1641,7 @@ static int
cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
if (err < 0)
return err;
-err = cbs_h266_replace_ph(ctx, unit);
+err = cbs_h266_replace_ph(ctx, unit,
>ph_picture_header);
if (err < 0)
return err;
}
@@ -1661,6 +1662,12 @@ static int
cbs_h266_write_nal_unit(CodedBitstreamContext *ctx,
if (err < 0)
return err;
+if (slice->header.sh_picture_header_in_slice_header_flag) {
+err = cbs_h266_replace_ph(ctx, unit,
>header.sh_picture_header);
+if (err < 0)
+return err;
+}
+
if (slice->data) {
err = cbs_h2645_write_slice_data(ctx, pbc,
slice->data,
slice->data_size,
@@ -1884,8 +1891,8 @@ static void cbs_h266_flush(CodedBitstreamContext
*ctx)
av_buffer_unref(>pps_ref[i]);
h266->pps[i] = NULL;
}
-av_buffer_unref(>priv.ph_ref);
-h266->priv.ph = NULL;
+av_buffer_unref(>ph_ref);
+h266->ph = NULL;
}
static void cbs_h266_close(CodedBitstreamContext *ctx)
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 03dfd4a954..54590748c3 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -581,8 +581,7 @@ typedef struct H266RawPredWeightTable {
int16_t delta_chroma_offset_l1[15][2];
} H266RawPredWeightTable;
-typedef struct H266RawPH {
-H266RawNALUnitHeader nal_unit_header;
+typedef struct H266RawPictureHeader {
uint8_t ph_gdr_or_irap_pic_flag;
uint8_t ph_non_ref_pic_flag;
uint8_t ph_gdr_pic_flag;
@@ -670,12 +669,17 @@ typedef struct H266RawPH {
uint8_t ph_extension_length;
uint8_t ph_extension_data_byte[256];
+} H266RawPictureHeader;
+
+typedef struct H266RawPH {
+
Re: [FFmpeg-devel] [PATCH v2] avformat/ivfenc: Set the "number of frames" in IVF header
Quoting Ronald S. Bultje (2023-07-02 14:44:42) > Hi, > > On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > > > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > > I see this discussion now... > > > > > > I don't think I agree with the above. First of all, IVF has two fields > > > there (it seems): duration, and n_frames. > > > > Got any source for that? I only see one field in > > https://wiki.multimedia.cx/index.php/Duck_IVF > > > > This somewhat-widely used tool called "ffmpeg" has used it like that for > the past, say, 10 years. I've heard some projects or companies around the > world use this tool, and backwards compatibility is supposedly a thing. Yeah yeah very funny. You claimed there are two fields. My question was where is this second field supposed to be. -- 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 v2] avformat/ivfenc: Set the "number of frames" in IVF header
Hi, On Sun, Jul 2, 2023 at 5:35 AM Anton Khirnov wrote: > Quoting Ronald S. Bultje (2023-07-02 02:03:11) > > I see this discussion now... > > > > I don't think I agree with the above. First of all, IVF has two fields > > there (it seems): duration, and n_frames. > > Got any source for that? I only see one field in > https://wiki.multimedia.cx/index.php/Duck_IVF > This somewhat-widely used tool called "ffmpeg" has used it like that for the past, say, 10 years. I've heard some projects or companies around the world use this tool, and backwards compatibility is supposedly a thing. 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".
Re: [FFmpeg-devel] [PATCH] cbs_h266: fix typo for ols_mode_idc == 2
On 7/2/2023 7:15 AM, Nuo Mi wrote: --- libavcodec/cbs_h266_syntax_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index f1cd45f815..ae44565a54 100644 --- a/libavcodec/cbs_h266_syntax_template.c +++ b/libavcodec/cbs_h266_syntax_template.c @@ -712,7 +712,7 @@ static int FUNC(vps) (CodedBitstreamContext *ctx, RWContext *rw, } if (ols_mode_idc == 4 || ols_mode_idc == 0 || ols_mode_idc == 1) total_num_olss = current->vps_max_layers_minus1 + 1; -else if (ols_mode_idc = 2) +else if (ols_mode_idc == 2) total_num_olss = current->vps_num_output_layer_sets_minus2 + 2; else av_log(ctx->log_ctx, AV_LOG_ERROR, Applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cbs_h266: fix sign for pps_xxx_qp_offset_list
On 7/2/2023 7:15 AM, Nuo Mi wrote:
---
libavcodec/cbs_h266.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 9e823919af..e33d08a0f5 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -520,9 +520,9 @@ typedef struct H266RawPPS {
uint8_t pps_slice_chroma_qp_offsets_present_flag;
uint8_t pps_cu_chroma_qp_offset_list_enabled_flag;
uint8_t pps_chroma_qp_offset_list_len_minus1;
-uint8_t pps_cb_qp_offset_list[6];
-uint8_t pps_cr_qp_offset_list[6];
-uint8_t pps_joint_cbcr_qp_offset_list[6];
+int8_t pps_cb_qp_offset_list[6];
+int8_t pps_cr_qp_offset_list[6];
+int8_t pps_joint_cbcr_qp_offset_list[6];
uint8_t pps_deblocking_filter_control_present_flag;
uint8_t pps_deblocking_filter_override_enabled_flag;
uint8_t pps_deblocking_filter_disabled_flag;
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 15/15] avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines
Round job start lines down to a multiple of 4. This means that if
filter_line3 exists then filter_line will not sometimes be called
once at the end of a slice depending on thread count. The final slice
may do up to 3 extra lines but filter_edge is faster than filter_line
so it is unlikely to create any noticable thread load variation.
Signed-off-by: John Cox
---
libavfilter/vf_bwdif.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 52bc676cf8..6701208efe 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -237,6 +237,13 @@ static void filter_edge_16bit(void *dst1, void *prev1,
void *cur1, void *next1,
FILTER2()
}
+// Round job start line down to multiple of 4 so that if filter_line3 exists
+// and the frame is a multiple of 4 high then filter_line will never be called
+static inline int job_start(const int jobnr, const int nb_jobs, const int h)
+{
+return jobnr >= nb_jobs ? h : ((h * jobnr) / nb_jobs) & ~3;
+}
+
static int filter_slice(AVFilterContext *ctx, void *arg, int jobnr, int
nb_jobs)
{
BWDIFContext *s = ctx->priv;
@@ -246,8 +253,8 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
int clip_max = (1 << (yadif->csp->comp[td->plane].depth)) - 1;
int df = (yadif->csp->comp[td->plane].depth + 7) / 8;
int refs = linesize / df;
-int slice_start = (td->h * jobnr ) / nb_jobs;
-int slice_end = (td->h * (jobnr+1)) / nb_jobs;
+int slice_start = job_start(jobnr, nb_jobs, td->h);
+int slice_end = job_start(jobnr + 1, nb_jobs, td->h);
int y;
for (y = slice_start; y < slice_end; y++) {
@@ -310,7 +317,7 @@ static void filter(AVFilterContext *ctx, AVFrame *dstpic,
td.plane = i;
ff_filter_execute(ctx, filter_slice, , NULL,
- FFMIN(h, ff_filter_get_nb_threads(ctx)));
+ FFMIN((h+3)/4, ff_filter_get_nb_threads(ctx)));
}
if (yadif->current_field == YADIF_FIELD_END) {
yadif->current_field = YADIF_FIELD_NORMAL;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 14/15] tests/checkasm: Add test for vf_bwdif filter_line3
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 81 +++
1 file changed, 81 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 5fdba09fdc..3399cacdf7 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -28,6 +28,10 @@
for (size_t i = 0; i < count; i++) \
buf0[i] = buf1[i] = rnd() & mask
+#define randomize_overflow_check(buf0, buf1, mask, count) \
+for (size_t i = 0; i < count; i++) \
+buf0[i] = buf1[i] = (rnd() & 1) != 0 ? mask : 0;
+
#define BODY(type, depth)
\
do {
\
type prev0[9*WIDTH], prev1[9*WIDTH];
\
@@ -83,6 +87,83 @@ void checkasm_check_vf_bwdif(void)
report("bwdif10");
}
+if (!ctx_8.filter_line3)
+ctx_8.filter_line3 = ff_bwdif_filter_line3_c;
+
+{
+LOCAL_ALIGNED_16(uint8_t, prev0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, prev1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0, [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1, [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+int parity;
+
+for (parity = 0; parity != 2; ++parity) {
+if (check_func(ctx_8.filter_line3, "bwdif8.line3.rnd.p%d",
parity)) {
+
+declare_func(void, void * dst1, int d_stride,
+ const void * prev1, const void *
cur1, const void * next1, int prefs,
+ int w, int parity, int clip_max);
+
+randomize_buffers(prev0, prev1, mask, 11*WIDTH);
+randomize_buffers(next0, next1, mask, 11*WIDTH);
+randomize_buffers( cur0, cur1, mask, 11*WIDTH);
+
+call_ref(dst0, stride,
+ prev0 + stride * 4, cur0 + stride * 4, next0 + stride
* 4, stride,
+ WIDTH, parity, mask);
+call_new(dst1, stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 + stride
* 4, stride,
+ WIDTH, parity, mask);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp(prev0, prev1, WIDTH*11)
+|| memcmp(next0, next1, WIDTH*11)
+|| memcmp( cur0, cur1, WIDTH*11))
+fail();
+
+bench_new(dst1, stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 + stride
* 4, stride,
+ WIDTH, parity, mask);
+}
+}
+
+// Use just 0s and ~0s to try to provoke bad cropping or overflow
+// Parity makes no difference to this test so just test 0
+if (check_func(ctx_8.filter_line3, "bwdif8.line3.overflow")) {
+
+declare_func(void, void * dst1, int d_stride,
+ const void * prev1, const void * cur1,
const void * next1, int prefs,
+ int w, int parity, int clip_max);
+
+randomize_overflow_check(prev0, prev1, mask, 11*WIDTH);
+randomize_overflow_check(next0, next1, mask, 11*WIDTH);
+randomize_overflow_check( cur0, cur1, mask, 11*WIDTH);
+
+call_ref(dst0, stride,
+ prev0 + stride * 4, cur0 + stride * 4, next0 + stride *
4, stride,
+ WIDTH, 0, mask);
+call_new(dst1, stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 + stride *
4, stride,
+ WIDTH, 0, mask);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp(prev0, prev1, WIDTH*11)
+|| memcmp(next0, next1, WIDTH*11)
+|| memcmp( cur0, cur1, WIDTH*11))
+fail();
+
+// No point to benching
+}
+
+report("bwdif8.line3");
+}
+
{
LOCAL_ALIGNED_16(uint8_t, prev0, [11*WIDTH]);
LOCAL_ALIGNED_16(uint8_t, prev1, [11*WIDTH]);
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 13/15] avfilter/vf_bwdif: Add neon for filter_line3
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 28 ++
libavfilter/aarch64/vf_bwdif_neon.S | 272
2 files changed, 300 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 21e67884ab..f52bc4b9b4 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -36,6 +36,33 @@ void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void
*cur1, void *next1,
int prefs3, int mrefs3, int prefs4, int mrefs4,
int parity, int clip_max);
+void ff_bwdif_filter_line3_neon(void * dst1, int d_stride,
+const void * prev1, const void * cur1, const
void * next1, int s_stride,
+int w, int parity, int clip_max);
+
+
+static void filter_line3_helper(void * dst1, int d_stride,
+const void * prev1, const void * cur1, const
void * next1, int s_stride,
+int w, int parity, int clip_max)
+{
+// Asm works on 16 byte chunks
+// If w is a multiple of 16 then all is good - if not then if width rounded
+// up to nearest 16 will fit in both src & dst strides then allow the asm
+// to write over the padding bytes as that is almost certainly faster than
+// having to invoke the C version to clean up the tail.
+const int w1 = FFALIGN(w, 16);
+const int w0 = clip_max != 255 ? 0 :
+ d_stride <= w1 && s_stride <= w1 ? w : w & ~15;
+
+ff_bwdif_filter_line3_neon(dst1, d_stride,
+ prev1, cur1, next1, s_stride,
+ w0, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line3_c((char *)dst1 + w0, d_stride,
+(const char *)prev1 + w0, (const char *)cur1 +
w0, (const char *)next1 + w0, s_stride,
+w - w0, parity, clip_max);
+}
static void filter_line_helper(void *dst1, void *prev1, void *cur1, void
*next1,
int w, int prefs, int mrefs, int prefs2, int
mrefs2,
@@ -93,5 +120,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
s->filter_intra = filter_intra_helper;
s->filter_line = filter_line_helper;
s->filter_edge = filter_edge_helper;
+s->filter_line3 = filter_line3_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index abc050565c..1405ea10fb 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -149,6 +149,278 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+// ===
+//
+// void ff_bwdif_filter_line3_neon(
+// void * dst1, // x0
+// int d_stride,// w1
+// const void * prev1, // x2
+// const void * cur1, // x3
+// const void * next1, // x4
+// int s_stride,// w5
+// int w, // w6
+// int parity, // w7
+// int clip_max); // [sp, #0] (Ignored)
+
+function ff_bwdif_filter_line3_neon, export=1
+// Sanity check w
+cmp w6, #0
+ble 99f
+
+// #define prev2 cur
+//const uint8_t * restrict next2 = parity ? prev : next;
+cmp w7, #0
+cselx17, x2, x4, ne
+
+// We want all the V registers - save all the ones we must
+PUSH_VREGS
+
+ldr q0, coeffs
+
+// Some rearrangement of initial values for nice layout of refs in regs
+mov w10, w6 // w10 = loop count
+neg w9, w5 // w9 = mref
+lsl w8, w9, #1// w8 = mref2
+add w7, w9, w9, LSL #1// w7 = mref3
+lsl w6, w9, #2// w6 = mref4
+mov w11, w5 // w11 = pref
+lsl w12, w5, #1// w12 = pref2
+add w13, w5, w5, LSL #1// w13 = pref3
+lsl w14, w5, #2// w14 = pref4
+add w15, w5, w5, LSL #2// w15 = pref5
+add w16, w14, w12 // w16 = pref6
+
+lsl w5, w1, #1// w5 = d_stride * 2
+
+// for (x = 0; x < w; x++) {
+// int diff0, diff2;
+// int d0, d2;
+// int temporal_diff0, temporal_diff2;
+//
+// int i1, i2;
+// int j1, j2;
+//
[FFmpeg-devel] [PATCH v2 12/15] avfilter/vf_bwdif: Add a filter_line3 method for optimisation
Add an optional filter_line3 to the available optimisations.
filter_line3 is equivalent to filter_line, memcpy, filter_line
filter_line shares quite a number of loads and some calculations in
common with its next iteration and testing shows that using aarch64
neon filter_line3s performance is 30% better than two filter_lines
and a memcpy.
Signed-off-by: John Cox
---
libavfilter/bwdif.h| 7 +++
libavfilter/vf_bwdif.c | 31 +++
2 files changed, 38 insertions(+)
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index cce99953f3..496cec72ef 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -35,6 +35,9 @@ typedef struct BWDIFContext {
void (*filter_edge)(void *dst, void *prev, void *cur, void *next,
int w, int prefs, int mrefs, int prefs2, int mrefs2,
int parity, int clip_max, int spat);
+void (*filter_line3)(void *dst, int dstride,
+ const void *prev, const void *cur, const void *next,
int prefs,
+ int w, int parity, int clip_max);
} BWDIFContext;
void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
@@ -53,4 +56,8 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1, void
*cur1, void *next1,
int prefs3, int mrefs3, int prefs4, int mrefs4,
int parity, int clip_max);
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void * cur1, const void
* next1, int s_stride,
+ int w, int parity, int clip_max);
+
#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 26349da1fd..52bc676cf8 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -150,6 +150,31 @@ void ff_bwdif_filter_line_c(void *dst1, void *prev1, void
*cur1, void *next1,
FILTER2()
}
+#define NEXT_LINE()\
+dst += d_stride; \
+prev += prefs; \
+cur += prefs; \
+next += prefs;
+
+void ff_bwdif_filter_line3_c(void * dst1, int d_stride,
+ const void * prev1, const void * cur1, const void
* next1, int s_stride,
+ int w, int parity, int clip_max)
+{
+const int prefs = s_stride;
+uint8_t * dst = dst1;
+const uint8_t * prev = prev1;
+const uint8_t * cur = cur1;
+const uint8_t * next = next1;
+
+ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
+ prefs, -prefs, prefs * 2, - prefs * 2, prefs * 3,
-prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
+NEXT_LINE();
+memcpy(dst, cur, w);
+NEXT_LINE();
+ff_bwdif_filter_line_c(dst, (void*)prev, (void*)cur, (void*)next, w,
+ prefs, -prefs, prefs * 2, - prefs * 2, prefs * 3,
-prefs * 3, prefs * 4, -prefs * 4, parity, clip_max);
+}
+
void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void *next1,
int w, int prefs, int mrefs, int prefs2, int
mrefs2,
int parity, int clip_max, int spat)
@@ -244,6 +269,11 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
refs << 1, -(refs << 1),
td->parity ^ td->tff, clip_max,
(y < 2) || ((y + 3) > td->h) ? 0 : 1);
+} else if (s->filter_line3 && y + 2 < slice_end && y + 6 < td->h) {
+s->filter_line3(dst, td->frame->linesize[td->plane],
+prev, cur, next, linesize, td->w,
+td->parity ^ td->tff, clip_max);
+y += 2;
} else {
s->filter_line(dst, prev, cur, next, td->w,
refs, -refs, refs << 1, -(refs << 1),
@@ -357,6 +387,7 @@ static int config_props(AVFilterLink *link)
av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int bit_depth)
{
+s->filter_line3 = 0;
if (bit_depth > 8) {
s->filter_intra = filter_intra_16bit;
s->filter_line = filter_line_c_16bit;
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 11/15] avfilter/vf_bwdif: Add neon for filter_line
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 21 ++
libavfilter/aarch64/vf_bwdif_neon.S | 208
2 files changed, 229 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index e75cf2f204..21e67884ab 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -31,6 +31,26 @@ void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void
*cur1, void *next1,
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max);
+
+
+static void filter_line_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int prefs3, int mrefs3, int prefs4, int mrefs4,
+ int parity, int clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_line_neon(dst1, prev1, cur1, next1,
+ w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_line_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2, prefs3,
mrefs3, prefs4, mrefs4, parity, clip_max);
+}
static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
*next1,
int w, int prefs, int mrefs, int prefs2, int
mrefs2,
@@ -71,6 +91,7 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_line = filter_line_helper;
s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index d6e7d109f5..abc050565c 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -149,6 +149,214 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+// ===
+//
+// void filter_line(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int prefs3, // [sp, #SP_INT]
+// int mrefs3, // [sp, #SP_INT*2]
+// int prefs4, // [sp, #SP_INT*3]
+// int mrefs4, // [sp, #SP_INT*4]
+// int parity, // [sp, #SP_INT*5]
+// int clip_max) // [sp, #SP_INT*6]
+
+function ff_bwdif_filter_line_neon, export=1
+// Sanity check w
+cmp w4, #0
+ble 99f
+
+// Rearrange regs to be the same as line3 for ease of debug!
+mov w10, w4 // w10 = loop count
+mov w9, w6 // w9 = mref
+mov w12, w7 // w12 = pref2
+mov w11, w5 // w11 = pref
+ldr w8, [sp, #0] // w8 = mref2
+ldr w7, [sp, #SP_INT*2]// w7 = mref3
+ldr w6, [sp, #SP_INT*4]// w6 = mref4
+ldr w13, [sp, #SP_INT] // w13 = pref3
+ldr w14, [sp, #SP_INT*3]// w14 = pref4
+
+mov x4, x3
+mov x3, x2
+mov x2, x1
+
+// #define prev2 cur
+//const uint8_t * restrict next2 = parity ? prev : next;
+ldr w17, [sp, #SP_INT*5]// parity
+cmp w17, #0
+cselx17, x2, x4, ne
+
+PUSH_VREGS
+
+ldr q0, coeffs
+
+// for (x = 0; x < w; x++) {
+// int diff0, diff2;
+// int d0, d2;
+// int temporal_diff0, temporal_diff2;
+//
+// int i1, i2;
+// int j1, j2;
+// int p6, p5, p4, p3, p2, p1, c0, m1, m2, m3, m4;
+
+10:
+// c0 = prev2[0] + next2[0];// c0 = v20, v21
+// d0 = c0 >> 1; // d0 = v10
+// temporal_diff0 = FFABS(prev2[0] -
[FFmpeg-devel] [PATCH v2 07/15] avfilter/vf_bwdif: Export C filter_edge
Needed for tail fixup of neon code
Signed-off-by: John Cox
---
libavfilter/bwdif.h| 4
libavfilter/vf_bwdif.c | 8
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index ae6f6ce223..ae1616d366 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -41,6 +41,10 @@ void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
bit_depth);
void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth);
void ff_bwdif_init_aarch64(BWDIFContext *bwdif, int bit_depth);
+void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void *next1,
+int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+int parity, int clip_max, int spat);
+
void ff_bwdif_filter_intra_c(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int clip_max);
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 035fc58670..bec83111b4 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -150,9 +150,9 @@ static void filter_line_c(void *dst1, void *prev1, void
*cur1, void *next1,
FILTER2()
}
-static void filter_edge(void *dst1, void *prev1, void *cur1, void *next1,
-int w, int prefs, int mrefs, int prefs2, int mrefs2,
-int parity, int clip_max, int spat)
+void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void *cur1, void *next1,
+int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+int parity, int clip_max, int spat)
{
uint8_t *dst = dst1;
uint8_t *prev = prev1;
@@ -364,7 +364,7 @@ av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int
bit_depth)
} else {
s->filter_intra = ff_bwdif_filter_intra_c;
s->filter_line = filter_line_c;
-s->filter_edge = filter_edge;
+s->filter_edge = ff_bwdif_filter_edge_c;
}
#if ARCH_X86
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 10/15] avfilter/vf_bwdif: Export C filter_line
Needed for tail fixup of neon code
Signed-off-by: John Cox
---
libavfilter/bwdif.h| 5 +
libavfilter/vf_bwdif.c | 10 +-
2 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index ae1616d366..cce99953f3 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -48,4 +48,9 @@ void ff_bwdif_filter_edge_c(void *dst1, void *prev1, void
*cur1, void *next1,
void ff_bwdif_filter_intra_c(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int clip_max);
+void ff_bwdif_filter_line_c(void *dst1, void *prev1, void *cur1, void *next1,
+int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+int prefs3, int mrefs3, int prefs4, int mrefs4,
+int parity, int clip_max);
+
#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index bec83111b4..26349da1fd 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -132,10 +132,10 @@ void ff_bwdif_filter_intra_c(void *dst1, void *cur1, int
w, int prefs, int mrefs
FILTER_INTRA()
}
-static void filter_line_c(void *dst1, void *prev1, void *cur1, void *next1,
- int w, int prefs, int mrefs, int prefs2, int mrefs2,
- int prefs3, int mrefs3, int prefs4, int mrefs4,
- int parity, int clip_max)
+void ff_bwdif_filter_line_c(void *dst1, void *prev1, void *cur1, void *next1,
+int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+int prefs3, int mrefs3, int prefs4, int mrefs4,
+int parity, int clip_max)
{
uint8_t *dst = dst1;
uint8_t *prev = prev1;
@@ -363,7 +363,7 @@ av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int
bit_depth)
s->filter_edge = filter_edge_16bit;
} else {
s->filter_intra = ff_bwdif_filter_intra_c;
-s->filter_line = filter_line_c;
+s->filter_line = ff_bwdif_filter_line_c;
s->filter_edge = ff_bwdif_filter_edge_c;
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 06/15] avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_neon.S | 73 +
1 file changed, 73 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 6a614f8d6e..48dc7bcd9d 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -66,6 +66,79 @@
umlsl2 \a3\().4s, \s1\().8h, \k
.endm
+// int b = m2s1 - m1;
+// int f = p2s1 - p1;
+// int dc = c0s1 - m1;
+// int de = c0s1 - p1;
+// int sp_max = FFMIN(p1 - c0s1, m1 - c0s1);
+// sp_max = FFMIN(sp_max, FFMAX(-b,-f));
+// int sp_min = FFMIN(c0s1 - p1, c0s1 - m1);
+// sp_min = FFMIN(sp_min, FFMAX(b,f));
+// diff = diff == 0 ? 0 : FFMAX3(diff, sp_min, sp_max);
+.macro SPAT_CHECK diff, m2s1, m1, c0s1, p1, p2s1, t0, t1, t2, t3
+uqsub \t0\().16b, \p1\().16b, \c0s1\().16b
+uqsub \t2\().16b, \m1\().16b, \c0s1\().16b
+umin\t2\().16b, \t0\().16b, \t2\().16b
+
+uqsub \t1\().16b, \m1\().16b, \m2s1\().16b
+uqsub \t3\().16b, \p1\().16b, \p2s1\().16b
+umax\t3\().16b, \t3\().16b, \t1\().16b
+umin\t3\().16b, \t3\().16b, \t2\().16b
+
+uqsub \t0\().16b, \c0s1\().16b, \p1\().16b
+uqsub \t2\().16b, \c0s1\().16b, \m1\().16b
+umin\t2\().16b, \t0\().16b, \t2\().16b
+
+uqsub \t1\().16b, \m2s1\().16b, \m1\().16b
+uqsub \t0\().16b, \p2s1\().16b, \p1\().16b
+umax\t0\().16b, \t0\().16b, \t1\().16b
+umin\t2\().16b, \t2\().16b, \t0\().16b
+
+cmeq\t1\().16b, \diff\().16b, #0
+umax\diff\().16b, \diff\().16b, \t3\().16b
+umax\diff\().16b, \diff\().16b, \t2\().16b
+bic \diff\().16b, \diff\().16b, \t1\().16b
+.endm
+
+// i0 = s0;
+// if (i0 > d0 + diff0)
+// i0 = d0 + diff0;
+// else if (i0 < d0 - diff0)
+// i0 = d0 - diff0;
+//
+// i0 = s0 is safe
+.macro DIFF_CLIP i0, s0, d0, diff, t0, t1
+uqadd \t0\().16b, \d0\().16b, \diff\().16b
+uqsub \t1\().16b, \d0\().16b, \diff\().16b
+umin\i0\().16b, \s0\().16b, \t0\().16b
+umax\i0\().16b, \i0\().16b, \t1\().16b
+.endm
+
+// i0 = FFABS(m1 - p1) > td0 ? i1 : i2;
+// DIFF_CLIP
+//
+// i0 = i1 is safe
+.macro INTERPOL i0, i1, i2, m1, d0, p1, td0, diff, t0, t1, t2
+uabd\t0\().16b, \m1\().16b, \p1\().16b
+cmhi\t0\().16b, \t0\().16b, \td0\().16b
+bsl \t0\().16b, \i1\().16b, \i2\().16b
+DIFF_CLIP \i0, \t0, \d0, \diff, \t1, \t2
+.endm
+
+.macro PUSH_VREGS
+stp d8, d9, [sp, #-64]!
+stp d10, d11, [sp, #16]
+stp d12, d13, [sp, #32]
+stp d14, d15, [sp, #48]
+.endm
+
+.macro POP_VREGS
+ldp d14, d15, [sp, #48]
+ldp d12, d13, [sp, #32]
+ldp d10, d11, [sp, #16]
+ldp d8, d9, [sp], #64
+.endm
+
// static const uint16_t coef_lf[2] = { 4309, 213 };
// static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
// static const uint16_t coef_sp[2] = { 5077, 981 };
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 05/15] tests/checkasm: Add test for vf_bwdif filter_intra
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 37 +
1 file changed, 37 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 46224bb575..034bbabb4c 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -20,6 +20,7 @@
#include "checkasm.h"
#include "libavcodec/internal.h"
#include "libavfilter/bwdif.h"
+#include "libavutil/mem_internal.h"
#define WIDTH 256
@@ -81,4 +82,40 @@ void checkasm_check_vf_bwdif(void)
BODY(uint16_t, 10);
report("bwdif10");
}
+
+if (check_func(ctx_8.filter_intra, "bwdif8.intra")) {
+LOCAL_ALIGNED_16(uint8_t, cur0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0, [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1, [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+
+declare_func(void, void *dst1, void *cur1, int w, int prefs, int mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+
+randomize_buffers( cur0, cur1, mask, 11*WIDTH);
+memset(dst0, 0xba, WIDTH * 3);
+memset(dst1, 0xba, WIDTH * 3);
+
+call_ref(dst0 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+call_new(dst1 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp( cur0, cur1, WIDTH*11))
+fail();
+
+bench_new(dst1 + stride,
+ cur0 + stride * 4, WIDTH,
+ stride, -stride, stride * 3, -stride * 3,
+ 0, mask);
+
+report("bwdif8.intra");
+}
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 09/15] tests/checkasm: Add test for vf_bwdif filter_edge
Signed-off-by: John Cox
---
tests/checkasm/vf_bwdif.c | 54 +++
1 file changed, 54 insertions(+)
diff --git a/tests/checkasm/vf_bwdif.c b/tests/checkasm/vf_bwdif.c
index 034bbabb4c..5fdba09fdc 100644
--- a/tests/checkasm/vf_bwdif.c
+++ b/tests/checkasm/vf_bwdif.c
@@ -83,6 +83,60 @@ void checkasm_check_vf_bwdif(void)
report("bwdif10");
}
+{
+LOCAL_ALIGNED_16(uint8_t, prev0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, prev1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, next1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur0, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, cur1, [11*WIDTH]);
+LOCAL_ALIGNED_16(uint8_t, dst0, [WIDTH*3]);
+LOCAL_ALIGNED_16(uint8_t, dst1, [WIDTH*3]);
+const int stride = WIDTH;
+const int mask = (1<<8)-1;
+int spat;
+int parity;
+
+for (spat = 0; spat != 2; ++spat) {
+for (parity = 0; parity != 2; ++parity) {
+if (check_func(ctx_8.filter_edge, "bwdif8.edge.s%d.p%d", spat,
parity)) {
+
+declare_func(void, void *dst1, void *prev1, void *cur1,
void *next1,
+int w, int prefs, int mrefs, int
prefs2, int mrefs2,
+int parity, int clip_max, int
spat);
+
+randomize_buffers(prev0, prev1, mask, 11*WIDTH);
+randomize_buffers(next0, next1, mask, 11*WIDTH);
+randomize_buffers( cur0, cur1, mask, 11*WIDTH);
+memset(dst0, 0xba, WIDTH * 3);
+memset(dst1, 0xba, WIDTH * 3);
+
+call_ref(dst0 + stride,
+ prev0 + stride * 4, cur0 + stride * 4, next0 +
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+call_new(dst1 + stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 +
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+
+if (memcmp(dst0, dst1, WIDTH*3)
+|| memcmp(prev0, prev1, WIDTH*11)
+|| memcmp(next0, next1, WIDTH*11)
+|| memcmp( cur0, cur1, WIDTH*11))
+fail();
+
+bench_new(dst1 + stride,
+ prev1 + stride * 4, cur1 + stride * 4, next1 +
stride * 4, WIDTH,
+ stride, -stride, stride * 2, -stride * 2,
+ parity, mask, spat);
+}
+}
+}
+
+report("bwdif8.edge");
+}
+
if (check_func(ctx_8.filter_intra, "bwdif8.intra")) {
LOCAL_ALIGNED_16(uint8_t, cur0, [11*WIDTH]);
LOCAL_ALIGNED_16(uint8_t, cur1, [11*WIDTH]);
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 08/15] avfilter/vf_bwdif: Add neon for filter_edge
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 20
libavfilter/aarch64/vf_bwdif_neon.S | 104
2 files changed, 124 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 3ffaa07ab3..e75cf2f204 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,10 +24,29 @@
#include "libavfilter/bwdif.h"
#include "libavutil/aarch64/cpu.h"
+void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat);
+
void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max);
+static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
*next1,
+ int w, int prefs, int mrefs, int prefs2, int
mrefs2,
+ int parity, int clip_max, int spat)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_edge_neon(dst1, prev1, cur1, next1, w0, prefs, mrefs,
prefs2, mrefs2,
+ parity, clip_max, spat);
+
+if (w0 < w)
+ff_bwdif_filter_edge_c((char *)dst1 + w0, (char *)prev1 + w0, (char
*)cur1 + w0, (char *)next1 + w0,
+ w - w0, prefs, mrefs, prefs2, mrefs2,
+ parity, clip_max, spat);
+}
+
static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int
mrefs,
int prefs3, int mrefs3, int parity, int
clip_max)
{
@@ -52,5 +71,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
return;
s->filter_intra = filter_intra_helper;
+s->filter_edge = filter_edge_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 48dc7bcd9d..d6e7d109f5 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -149,6 +149,110 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+//
+//
+// void ff_bwdif_filter_edge_neon(
+// void *dst1, // x0
+// void *prev1,// x1
+// void *cur1, // x2
+// void *next1,// x3
+// int w, // w4
+// int prefs, // w5
+// int mrefs, // w6
+// int prefs2, // w7
+// int mrefs2, // [sp, #0]
+// int parity, // [sp, #SP_INT]
+// int clip_max, // [sp, #SP_INT*2] unused
+// int spat); // [sp, #SP_INT*3]
+
+function ff_bwdif_filter_edge_neon, export=1
+// Sanity check w
+cmp w4, #0
+ble 99f
+
+// #define prev2 cur
+// const uint8_t * restrict next2 = parity ? prev : next;
+
+ldr w8, [sp, #0] // mrefs2
+
+ldr w17, [sp, #SP_INT] // parity
+ldr w16, [sp, #SP_INT*3]// spat
+cmp w17, #0
+cselx17, x1, x3, ne
+
+// for (x = 0; x < w; x++) {
+
+10:
+//int m1 = cur[mrefs];
+//int d = (prev2[0] + next2[0]) >> 1;
+//int p1 = cur[prefs];
+//int temporal_diff0 = FFABS(prev2[0] - next2[0]);
+//int temporal_diff1 =(FFABS(prev[mrefs] - m1) + FFABS(prev[prefs] -
p1)) >> 1;
+//int temporal_diff2 =(FFABS(next[mrefs] - m1) + FFABS(next[prefs] -
p1)) >> 1;
+//int diff = FFMAX3(temporal_diff0 >> 1, temporal_diff1,
temporal_diff2);
+ldr q31, [x2]
+ldr q21, [x17]
+uhadd v16.16b, v31.16b, v21.16b // d0 = v16
+uabdv17.16b, v31.16b, v21.16b // td0 = v17
+ldr q24, [x2, w6, sxtw] // m1 = v24
+ldr q22, [x2, w5, sxtw] // p1 = v22
+
+ldr q0, [x1, w6, sxtw] // prev[mrefs]
+ldr q2, [x1, w5, sxtw] // prev[prefs]
+ldr q1, [x3, w6, sxtw] // next[mrefs]
+ldr q3, [x3, w5, sxtw] // next[prefs]
+
+ushrv29.16b, v17.16b, #1
+
+uabdv31.16b, v0.16b, v24.16b
+uabdv30.16b, v2.16b, v22.16b
+uhadd v0.16b, v31.16b, v30.16b // td1 = q0
+
+uabdv31.16b, v1.16b, v24.16b
+uabdv30.16b, v3.16b, v22.16b
+uhadd v1.16b, v31.16b, v30.16b // td2 = q1
+
+umax
[FFmpeg-devel] [PATCH v2 04/15] avfilter/vf_bwdif: Add neon for filter_intra
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 17 +++
libavfilter/aarch64/vf_bwdif_neon.S | 53 +
2 files changed, 70 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
index 86d53b2ca1..3ffaa07ab3 100644
--- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -24,6 +24,22 @@
#include "libavfilter/bwdif.h"
#include "libavutil/aarch64/cpu.h"
+void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+int prefs3, int mrefs3, int parity, int
clip_max);
+
+
+static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+int prefs3, int mrefs3, int parity, int
clip_max)
+{
+const int w0 = clip_max != 255 ? 0 : w & ~15;
+
+ff_bwdif_filter_intra_neon(dst1, cur1, w0, prefs, mrefs, prefs3, mrefs3,
parity, clip_max);
+
+if (w0 < w)
+ff_bwdif_filter_intra_c((char *)dst1 + w0, (char *)cur1 + w0,
+w - w0, prefs, mrefs, prefs3, mrefs3, parity,
clip_max);
+}
+
void
ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
{
@@ -35,5 +51,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
if (!have_neon(cpu_flags))
return;
+s->filter_intra = filter_intra_helper;
}
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index c2f5eb1f73..6a614f8d6e 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -76,3 +76,56 @@ coeffs:
.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
.hword 5077, 981 // sp[0] = v0.h[6]
+//
+//
+// void ff_bwdif_filter_intra_neon(
+// void *dst1, // x0
+// void *cur1, // x1
+// int w, // w2
+// int prefs, // w3
+// int mrefs, // w4
+// int prefs3, // w5
+// int mrefs3, // w6
+// int parity, // w7 unused
+// int clip_max) // [sp, #0] unused
+
+function ff_bwdif_filter_intra_neon, export=1
+cmp w2, #0
+ble 99f
+
+ldr q0, coeffs
+
+//for (x = 0; x < w; x++) {
+10:
+
+//interpol = (coef_sp[0] * (cur[mrefs] + cur[prefs]) - coef_sp[1] *
(cur[mrefs3] + cur[prefs3])) >> 13;
+ldr q31, [x1, w4, sxtw]
+ldr q30, [x1, w3, sxtw]
+ldr q29, [x1, w6, sxtw]
+ldr q28, [x1, w5, sxtw]
+
+uaddl v20.8h, v31.8b, v30.8b
+uaddl2 v21.8h, v31.16b, v30.16b
+
+UMULL4K v2, v3, v4, v5, v20, v21, v0.h[6]
+
+uaddl v20.8h, v29.8b, v28.8b
+uaddl2 v21.8h, v29.16b, v28.16b
+
+UMLSL4K v2, v3, v4, v5, v20, v21, v0.h[7]
+
+//dst[0] = av_clip(interpol, 0, clip_max);
+SQSHRUNNv2, v2, v3, v4, v5, 13
+str q2, [x0], #16
+
+//dst++;
+//cur++;
+//}
+
+subsw2, w2, #16
+add x1, x1, #16
+bgt 10b
+
+99:
+ret
+endfunc
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 03/15] avfilter/vf_bwdif: Export C filter_intra
Needed for tail fixup of neon code
Signed-off-by: John Cox
---
libavfilter/bwdif.h| 3 +++
libavfilter/vf_bwdif.c | 6 +++---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index 6a0f70487a..ae6f6ce223 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -41,4 +41,7 @@ void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int
bit_depth);
void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth);
void ff_bwdif_init_aarch64(BWDIFContext *bwdif, int bit_depth);
+void ff_bwdif_filter_intra_c(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max);
+
#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index 39a51429ac..035fc58670 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -122,8 +122,8 @@ typedef struct ThreadData {
next2++; \
}
-static void filter_intra(void *dst1, void *cur1, int w, int prefs, int mrefs,
- int prefs3, int mrefs3, int parity, int clip_max)
+void ff_bwdif_filter_intra_c(void *dst1, void *cur1, int w, int prefs, int
mrefs,
+ int prefs3, int mrefs3, int parity, int clip_max)
{
uint8_t *dst = dst1;
uint8_t *cur = cur1;
@@ -362,7 +362,7 @@ av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int
bit_depth)
s->filter_line = filter_line_c_16bit;
s->filter_edge = filter_edge_16bit;
} else {
-s->filter_intra = filter_intra;
+s->filter_intra = ff_bwdif_filter_intra_c;
s->filter_line = filter_line_c;
s->filter_edge = filter_edge;
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
Add macros for dual scalar half->single multiply and accumulate
Add macro for shift, saturate and shorten single to byte
Add filter constants
Signed-off-by: John Cox
---
libavfilter/aarch64/vf_bwdif_neon.S | 53 +
1 file changed, 53 insertions(+)
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
index 639ab22998..c2f5eb1f73 100644
--- a/libavfilter/aarch64/vf_bwdif_neon.S
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -23,3 +23,56 @@
#include "libavutil/aarch64/asm.S"
+// Space taken on the stack by an int (32-bit)
+#ifdef __APPLE__
+.setSP_INT, 4
+#else
+.setSP_INT, 8
+#endif
+
+.macro SQSHRUNN b, s0, s1, s2, s3, n
+sqshrun \s0\().4h, \s0\().4s, #\n - 8
+sqshrun2\s0\().8h, \s1\().4s, #\n - 8
+sqshrun \s1\().4h, \s2\().4s, #\n - 8
+sqshrun2\s1\().8h, \s3\().4s, #\n - 8
+uzp2\b\().16b, \s0\().16b, \s1\().16b
+.endm
+
+.macro SMULL4K a0, a1, a2, a3, s0, s1, k
+smull \a0\().4s, \s0\().4h, \k
+smull2 \a1\().4s, \s0\().8h, \k
+smull \a2\().4s, \s1\().4h, \k
+smull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMULL4K a0, a1, a2, a3, s0, s1, k
+umull \a0\().4s, \s0\().4h, \k
+umull2 \a1\().4s, \s0\().8h, \k
+umull \a2\().4s, \s1\().4h, \k
+umull2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLAL4K a0, a1, a2, a3, s0, s1, k
+umlal \a0\().4s, \s0\().4h, \k
+umlal2 \a1\().4s, \s0\().8h, \k
+umlal \a2\().4s, \s1\().4h, \k
+umlal2 \a3\().4s, \s1\().8h, \k
+.endm
+
+.macro UMLSL4K a0, a1, a2, a3, s0, s1, k
+umlsl \a0\().4s, \s0\().4h, \k
+umlsl2 \a1\().4s, \s0\().8h, \k
+umlsl \a2\().4s, \s1\().4h, \k
+umlsl2 \a3\().4s, \s1\().8h, \k
+.endm
+
+// static const uint16_t coef_lf[2] = { 4309, 213 };
+// static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
+// static const uint16_t coef_sp[2] = { 5077, 981 };
+
+.balign 16
+coeffs:
+.hword 4309 * 4, 213 * 4 // lf[0]*4 = v0.h[0]
+.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
-hf[1] = v0.h[5]
+.hword 5077, 981 // sp[0] = v0.h[6]
+
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 01/15] avfilter/vf_bwdif: Add outline for aarch neon functions
Outline but no actual functions.
Signed-off-by: John Cox
---
libavfilter/aarch64/Makefile| 2 ++
libavfilter/aarch64/vf_bwdif_init_aarch64.c | 39 +
libavfilter/aarch64/vf_bwdif_neon.S | 25 +
libavfilter/bwdif.h | 1 +
libavfilter/vf_bwdif.c | 2 ++
5 files changed, 69 insertions(+)
create mode 100644 libavfilter/aarch64/vf_bwdif_init_aarch64.c
create mode 100644 libavfilter/aarch64/vf_bwdif_neon.S
diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index b58daa3a3f..b68209bc94 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,3 +1,5 @@
+OBJS-$(CONFIG_BWDIF_FILTER) += aarch64/vf_bwdif_init_aarch64.o
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
+NEON-OBJS-$(CONFIG_BWDIF_FILTER) += aarch64/vf_bwdif_neon.o
NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
new file mode 100644
index 00..86d53b2ca1
--- /dev/null
+++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
@@ -0,0 +1,39 @@
+/*
+ * bwdif aarch64 NEON optimisations
+ *
+ * Copyright (c) 2023 John Cox
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/common.h"
+#include "libavfilter/bwdif.h"
+#include "libavutil/aarch64/cpu.h"
+
+void
+ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
+{
+const int cpu_flags = av_get_cpu_flags();
+
+if (bit_depth != 8)
+return;
+
+if (!have_neon(cpu_flags))
+return;
+
+}
+
diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
b/libavfilter/aarch64/vf_bwdif_neon.S
new file mode 100644
index 00..639ab22998
--- /dev/null
+++ b/libavfilter/aarch64/vf_bwdif_neon.S
@@ -0,0 +1,25 @@
+/*
+ * bwdif aarch64 NEON optimisations
+ *
+ * Copyright (c) 2023 John Cox
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+
+#include "libavutil/aarch64/asm.S"
+
diff --git a/libavfilter/bwdif.h b/libavfilter/bwdif.h
index 5749345f78..6a0f70487a 100644
--- a/libavfilter/bwdif.h
+++ b/libavfilter/bwdif.h
@@ -39,5 +39,6 @@ typedef struct BWDIFContext {
void ff_bwdif_init_filter_line(BWDIFContext *bwdif, int bit_depth);
void ff_bwdif_init_x86(BWDIFContext *bwdif, int bit_depth);
+void ff_bwdif_init_aarch64(BWDIFContext *bwdif, int bit_depth);
#endif /* AVFILTER_BWDIF_H */
diff --git a/libavfilter/vf_bwdif.c b/libavfilter/vf_bwdif.c
index e278cf1217..39a51429ac 100644
--- a/libavfilter/vf_bwdif.c
+++ b/libavfilter/vf_bwdif.c
@@ -369,6 +369,8 @@ av_cold void ff_bwdif_init_filter_line(BWDIFContext *s, int
bit_depth)
#if ARCH_X86
ff_bwdif_init_x86(s, bit_depth);
+#elif ARCH_AARCH64
+ff_bwdif_init_aarch64(s, bit_depth);
#endif
}
--
2.39.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 00/15] avfilter/vf_bwdif: Add aarch64 neon functions
Also adds a filter_line3 method which on aarch64 neon yields approx 30% speedup over 2xfilter_line and a memcpy Differences from v1: .align 16 corrected to .balign 16 SXTW tolower Mac ABI (hopefully) fixed V register pop/push macroed & prettified John Cox (15): avfilter/vf_bwdif: Add outline for aarch neon functions avfilter/vf_bwdif: Add common macros and consts for aarch64 neon avfilter/vf_bwdif: Export C filter_intra avfilter/vf_bwdif: Add neon for filter_intra tests/checkasm: Add test for vf_bwdif filter_intra avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon avfilter/vf_bwdif: Export C filter_edge avfilter/vf_bwdif: Add neon for filter_edge tests/checkasm: Add test for vf_bwdif filter_edge avfilter/vf_bwdif: Export C filter_line avfilter/vf_bwdif: Add neon for filter_line avfilter/vf_bwdif: Add a filter_line3 method for optimisation avfilter/vf_bwdif: Add neon for filter_line3 tests/checkasm: Add test for vf_bwdif filter_line3 avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines libavfilter/aarch64/Makefile| 2 + libavfilter/aarch64/vf_bwdif_init_aarch64.c | 125 libavfilter/aarch64/vf_bwdif_neon.S | 788 libavfilter/bwdif.h | 20 + libavfilter/vf_bwdif.c | 70 +- tests/checkasm/vf_bwdif.c | 172 + 6 files changed, 1162 insertions(+), 15 deletions(-) create mode 100644 libavfilter/aarch64/vf_bwdif_init_aarch64.c create mode 100644 libavfilter/aarch64/vf_bwdif_neon.S -- 2.39.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avutil/dict: add av_dict_pop
On 2 Jul 2023, at 10:43, Stefano Sabatini wrote:
> On date Sunday 2023-06-25 12:49:05 +0200, Marvin Scholz wrote:
>> This new API allows to remove an entry and obtain ownership of the
>> key/value that was associated with the removed entry.
>> ---
>>
>> Changes since v1:
>> - Clarify documentation about av_free having to be used.
>> - Fix fate test to not rely on specific error code value
>>
>> doc/APIchanges | 4
>> libavutil/dict.c | 27 +++
>> libavutil/dict.h | 26 ++
>> libavutil/tests/dict.c | 38 ++
>> libavutil/version.h| 4 ++--
>> tests/ref/fate/dict| 12
>> 6 files changed, 109 insertions(+), 2 deletions(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index f040211f7d..d55821f682 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -2,6 +2,10 @@ The last version increases of all libraries were on
>> 2023-02-09
>>
>> API changes, most recent first:
>>
>> +2023-06-02 - xx - lavu 58.14.100 - dict.h
>> + Add av_dict_pop() to remove an entry from a dict
>> + and get ownership of the removed key/value.
>> +
>> 2023-05-29 - xx - lavc 60.16.100 - avcodec.h codec_id.h
>>Add AV_CODEC_ID_EVC, FF_PROFILE_EVC_BASELINE, and FF_PROFILE_EVC_MAIN.
>>
>> diff --git a/libavutil/dict.c b/libavutil/dict.c
>> index f673977a98..ac41771994 100644
>> --- a/libavutil/dict.c
>> +++ b/libavutil/dict.c
>> @@ -173,6 +173,33 @@ int av_dict_set_int(AVDictionary **pm, const char *key,
>> int64_t value,
>> return av_dict_set(pm, key, valuestr, flags);
>> }
>>
>> +int av_dict_pop(AVDictionary **pm, const char *key,
>> +char **out_key, char **out_value, int flags)
>> +{
>> +AVDictionary *m = *pm;
>> +AVDictionaryEntry *entry = NULL;
>> +entry = (AVDictionaryEntry *)av_dict_get(m, key, NULL, flags);
>> +if (!entry)
>> +return AVERROR(ENOENT);
>> +
>> +if (out_key)
>> +*out_key = entry->key;
>> +else
>> +av_free(entry->key);
>> +
>> +if (out_value)
>> +*out_value = entry->value;
>> +else
>> +av_free(entry->value);
>> +
>> +*entry = m->elems[--m->count];
>> +if (m && !m->count) {
>> +av_freep(>elems);
>> +av_freep(pm);
>> +}
>> +return 0;
>> +}
>> +
>> static int parse_key_value_pair(AVDictionary **pm, const char **buf,
>> const char *key_val_sep, const char
>> *pairs_sep,
>> int flags)
>> diff --git a/libavutil/dict.h b/libavutil/dict.h
>> index 713c9e361a..31d38dabec 100644
>> --- a/libavutil/dict.h
>> +++ b/libavutil/dict.h
>> @@ -172,6 +172,32 @@ int av_dict_set(AVDictionary **pm, const char *key,
>> const char *value, int flags
>> */
>> int av_dict_set_int(AVDictionary **pm, const char *key, int64_t value, int
>> flags);
>>
>> +/**
>> + * Remove the entry with the given key from the dictionary.
>> + *
>> + * Search for an entry matching @p key and remove it, if found. Optionally
>> + * the found key and/or value can be returned using the @p out_key and
>> + * @p out_value arguments.
>
> Note: I checked the code and we see that in some cases we use `param`
> (e.g. in mem.h) but I prefer this format (although apparently not used
> in other places) since it looks more consistent with the doxygen
> syntax.
>
>> + *
>> + * If more than one entry matches, only one entry is removed and returned
>> + * on each call. Which entry is returned first in that case is undefined.
>> + *
>> + * @param pmPointer to a pointer to a dictionary struct.
>> + * @param key Entry key to match.
>> + * @param out_key Pointer whose pointee will be set to the matched
>> + * entry key. Must be freed using av_dict_free() by
>> + * the caller. May be NULL.
>> + * @param out_value Pointer whose pointee will be set to the matched
>> + * entry value. Must be freed using av_dict_free() by
>> + * the caller. May be NULL.
>
> missing docs for flags, something like:
> @param flags flags passed to av_dict_get to look for the entry
>
> should be fine
>
Can whoever ends up merging this maybe add that?
If not, I can send a new revision with this change next weekend or so.
> [...]
>
> Looks good otherwise, thanks.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 v6 0/1] avformat: add Software Defined Radio support
On Fri, Jun 30, 2023 at 04:38:46PM +0200, Jean-Baptiste Kempf wrote: > On Fri, 30 Jun 2023, at 16:08, Michael Niedermayer wrote: > > Also as said previously, If there is at least a 2nd developer working > > on this then we could & should move this to a seperate libraray (libavradio) > > Why wait for a 2nd dev? as libavradio so far has been the only actionable suggestion. ill move the code to that and next revission or the one after that will be in libavradio. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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 11/15] avfilter/vf_bwdif: Add neon for filter_line
On Sun, 2 Jul 2023 00:44:10 +0300 (EEST), you wrote:
>On Thu, 29 Jun 2023, John Cox wrote:
>
>> Signed-off-by: John Cox
>> ---
>> libavfilter/aarch64/vf_bwdif_init_aarch64.c | 21 ++
>> libavfilter/aarch64/vf_bwdif_neon.S | 215
>> 2 files changed, 236 insertions(+)
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> index e75cf2f204..21e67884ab 100644
>> --- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> +++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> @@ -31,6 +31,26 @@ void ff_bwdif_filter_edge_neon(void *dst1, void *prev1,
>> void *cur1, void *next1,
>> void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs,
>> int mrefs,
>> int prefs3, int mrefs3, int parity, int
>> clip_max);
>>
>> +void ff_bwdif_filter_line_neon(void *dst1, void *prev1, void *cur1, void
>> *next1,
>> + int w, int prefs, int mrefs, int prefs2, int
>> mrefs2,
>> + int prefs3, int mrefs3, int prefs4, int
>> mrefs4,
>> + int parity, int clip_max);
>> +
>> +
>> +static void filter_line_helper(void *dst1, void *prev1, void *cur1, void
>> *next1,
>> + int w, int prefs, int mrefs, int prefs2, int
>> mrefs2,
>> + int prefs3, int mrefs3, int prefs4, int
>> mrefs4,
>> + int parity, int clip_max)
>> +{
>> +const int w0 = clip_max != 255 ? 0 : w & ~15;
>> +
>> +ff_bwdif_filter_line_neon(dst1, prev1, cur1, next1,
>> + w0, prefs, mrefs, prefs2, mrefs2, prefs3,
>> mrefs3, prefs4, mrefs4, parity, clip_max);
>> +
>> +if (w0 < w)
>> +ff_bwdif_filter_line_c((char *)dst1 + w0, (char *)prev1 + w0, (char
>> *)cur1 + w0, (char *)next1 + w0,
>> + w - w0, prefs, mrefs, prefs2, mrefs2,
>> prefs3, mrefs3, prefs4, mrefs4, parity, clip_max);
>> +}
>>
>> static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
>> *next1,
>>int w, int prefs, int mrefs, int prefs2, int
>> mrefs2,
>> @@ -71,6 +91,7 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
>> return;
>>
>> s->filter_intra = filter_intra_helper;
>> +s->filter_line = filter_line_helper;
>> s->filter_edge = filter_edge_helper;
>> }
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
>> b/libavfilter/aarch64/vf_bwdif_neon.S
>> index a33b235882..675e97d966 100644
>> --- a/libavfilter/aarch64/vf_bwdif_neon.S
>> +++ b/libavfilter/aarch64/vf_bwdif_neon.S
>> @@ -128,6 +128,221 @@ coeffs:
>> .hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
>> -hf[1] = v0.h[5]
>> .hword 5077, 981 // sp[0] = v0.h[6]
>>
>> +//
>> ===
>> +//
>> +// void filter_line(
>> +// void *dst1, // x0
>> +// void *prev1,// x1
>> +// void *cur1, // x2
>> +// void *next1,// x3
>> +// int w, // w4
>> +// int prefs, // w5
>> +// int mrefs, // w6
>> +// int prefs2, // w7
>> +// int mrefs2, // [sp, #0]
>> +// int prefs3, // [sp, #8]
>> +// int mrefs3, // [sp, #16]
>> +// int prefs4, // [sp, #24]
>> +// int mrefs4, // [sp, #32]
>> +// int parity, // [sp, #40]
>> +// int clip_max) // [sp, #48]
>> +
>> +function ff_bwdif_filter_line_neon, export=1
>> +// Sanity check w
>> +cmp w4, #0
>> +ble 99f
>> +
>> +// Rearrange regs to be the same as line3 for ease of debug!
>> +mov w10, w4 // w10 = loop count
>> +mov w9, w6 // w9 = mref
>> +mov w12, w7 // w12 = pref2
>> +mov w11, w5 // w11 = pref
>> +ldr w8, [sp, #0] // w8 = mref2
>> +ldr w7, [sp, #16] // w7 = mref3
>> +ldr w6, [sp, #32] // w6 = mref4
>> +ldr w13, [sp, #8] // w13 = pref3
>> +ldr w14, [sp, #24] // w14 = pref4
>
>Btw, remember that you can load two arguments from the stack at once with
>ldp, e.g. "ldp x8, x13, [sp, #0]". If they're made intptr_t/ptrdiff_t, you
>won't have an issue with garbage in the upper 32 bits either.
Fair point - I was indeed worrying about garbage in the upper half (and
this is not performance or size critical code).
>> +
>> +mov x4, x3
>> +mov x3, x2
>> +mov x2, x1
>> +
>> +// #define prev2 cur
>> +//const uint8_t *
Re: [FFmpeg-devel] [PATCH 08/15] avfilter/vf_bwdif: Add neon for filter_edge
On Sun, 2 Jul 2023 00:40:09 +0300 (EEST), you wrote:
>On Thu, 29 Jun 2023, John Cox wrote:
>
>> Signed-off-by: John Cox
>> ---
>> libavfilter/aarch64/vf_bwdif_init_aarch64.c | 20
>> libavfilter/aarch64/vf_bwdif_neon.S | 104
>> 2 files changed, 124 insertions(+)
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> index 3ffaa07ab3..e75cf2f204 100644
>> --- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> +++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> @@ -24,10 +24,29 @@
>> #include "libavfilter/bwdif.h"
>> #include "libavutil/aarch64/cpu.h"
>>
>> +void ff_bwdif_filter_edge_neon(void *dst1, void *prev1, void *cur1, void
>> *next1,
>> + int w, int prefs, int mrefs, int prefs2, int
>> mrefs2,
>> + int parity, int clip_max, int spat);
>> +
>> void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs,
>> int mrefs,
>> int prefs3, int mrefs3, int parity, int
>> clip_max);
>>
>>
>> +static void filter_edge_helper(void *dst1, void *prev1, void *cur1, void
>> *next1,
>> + int w, int prefs, int mrefs, int prefs2, int
>> mrefs2,
>> + int parity, int clip_max, int spat)
>> +{
>> +const int w0 = clip_max != 255 ? 0 : w & ~15;
>> +
>> +ff_bwdif_filter_edge_neon(dst1, prev1, cur1, next1, w0, prefs, mrefs,
>> prefs2, mrefs2,
>> + parity, clip_max, spat);
>> +
>> +if (w0 < w)
>> +ff_bwdif_filter_edge_c((char *)dst1 + w0, (char *)prev1 + w0, (char
>> *)cur1 + w0, (char *)next1 + w0,
>> + w - w0, prefs, mrefs, prefs2, mrefs2,
>> + parity, clip_max, spat);
>> +}
>> +
>> static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs,
>> int mrefs,
>> int prefs3, int mrefs3, int parity, int
>> clip_max)
>> {
>> @@ -52,5 +71,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
>> return;
>>
>> s->filter_intra = filter_intra_helper;
>> +s->filter_edge = filter_edge_helper;
>> }
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
>> b/libavfilter/aarch64/vf_bwdif_neon.S
>> index 6c5d1598f4..a33b235882 100644
>> --- a/libavfilter/aarch64/vf_bwdif_neon.S
>> +++ b/libavfilter/aarch64/vf_bwdif_neon.S
>> @@ -128,6 +128,110 @@ coeffs:
>> .hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
>> -hf[1] = v0.h[5]
>> .hword 5077, 981 // sp[0] = v0.h[6]
>>
>> +//
>>
>> +//
>> +// void ff_bwdif_filter_edge_neon(
>> +// void *dst1, // x0
>> +// void *prev1,// x1
>> +// void *cur1, // x2
>> +// void *next1,// x3
>> +// int w, // w4
>> +// int prefs, // w5
>> +// int mrefs, // w6
>> +// int prefs2, // w7
>> +// int mrefs2, // [sp, #0]
>> +// int parity, // [sp, #8]
>> +// int clip_max, // [sp, #16] unused
>> +// int spat); // [sp, #24]
>
>This doesn't hold for macOS targets (and the checkasm tests fail on that
>platform).
>
>On macOS, arguments that aren't passed in registers but on the stack, are
>tightly packed. So since parity is 32 bit and mrefs2 also was 32 bit,
>parity is available at [sp, #4].
>
>Therefore, it's usually simplest for portability reasons, to pass any
>arguments after the first 8, as intptr_t or ptrdiff_t, as that makes them
>consistent across platforms.
Not my interface - this is already existing code. What do you suggest I
do?
I'm happy either to change the interface or fix my stack offsets if
there is any clue that lets me detect this ABI. As personal preference
I'd choose the latter.
I don't have easy access to a mac. Is there any easy way of getting this
tested before resubmission?
Thanks
JC
>// 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 v6 0/1] avformat: add Software Defined Radio support
On Sun, 2 Jul 2023, at 11:58, Nicolas George wrote: >> Even if it is disabled by default, git master isn't a playground for >> personal projects. > > Yes it is. Absolutely not. You are the only one who believes that. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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 04/15] avfilter/vf_bwdif: Add neon for filter_intra
On Sun, 2 Jul 2023 00:37:35 +0300 (EEST), you wrote:
>On Thu, 29 Jun 2023, John Cox wrote:
>
>> Signed-off-by: John Cox
>> ---
>> libavfilter/aarch64/vf_bwdif_init_aarch64.c | 17 +++
>> libavfilter/aarch64/vf_bwdif_neon.S | 53 +
>> 2 files changed, 70 insertions(+)
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> index 86d53b2ca1..3ffaa07ab3 100644
>> --- a/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> +++ b/libavfilter/aarch64/vf_bwdif_init_aarch64.c
>> @@ -24,6 +24,22 @@
>> #include "libavfilter/bwdif.h"
>> #include "libavutil/aarch64/cpu.h"
>>
>> +void ff_bwdif_filter_intra_neon(void *dst1, void *cur1, int w, int prefs,
>> int mrefs,
>> +int prefs3, int mrefs3, int parity, int
>> clip_max);
>> +
>> +
>> +static void filter_intra_helper(void *dst1, void *cur1, int w, int prefs,
>> int mrefs,
>> +int prefs3, int mrefs3, int parity, int
>> clip_max)
>> +{
>> +const int w0 = clip_max != 255 ? 0 : w & ~15;
>> +
>> +ff_bwdif_filter_intra_neon(dst1, cur1, w0, prefs, mrefs, prefs3,
>> mrefs3, parity, clip_max);
>> +
>> +if (w0 < w)
>> +ff_bwdif_filter_intra_c((char *)dst1 + w0, (char *)cur1 + w0,
>> +w - w0, prefs, mrefs, prefs3, mrefs3,
>> parity, clip_max);
>> +}
>> +
>> void
>> ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
>> {
>> @@ -35,5 +51,6 @@ ff_bwdif_init_aarch64(BWDIFContext *s, int bit_depth)
>> if (!have_neon(cpu_flags))
>> return;
>>
>> +s->filter_intra = filter_intra_helper;
>> }
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
>> b/libavfilter/aarch64/vf_bwdif_neon.S
>> index a8f0ed525a..b863b3447d 100644
>> --- a/libavfilter/aarch64/vf_bwdif_neon.S
>> +++ b/libavfilter/aarch64/vf_bwdif_neon.S
>> @@ -69,3 +69,56 @@ coeffs:
>> .hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
>> -hf[1] = v0.h[5]
>> .hword 5077, 981 // sp[0] = v0.h[6]
>>
>> +//
>>
>> +//
>> +// void ff_bwdif_filter_intra_neon(
>> +// void *dst1, // x0
>> +// void *cur1, // x1
>> +// int w, // w2
>> +// int prefs, // w3
>> +// int mrefs, // w4
>> +// int prefs3, // w5
>> +// int mrefs3, // w6
>> +// int parity, // w7 unused
>> +// int clip_max) // [sp, #0] unused
>
>This bit is great to have
>
>> +
>> +function ff_bwdif_filter_intra_neon, export=1
>> +cmp w2, #0
>> +ble 99f
>> +
>> +ldr q0, coeffs
>> +
>> +//for (x = 0; x < w; x++) {
>> +10:
>> +
>> +//interpol = (coef_sp[0] * (cur[mrefs] + cur[prefs]) - coef_sp[1] *
>> (cur[mrefs3] + cur[prefs3])) >> 13;
>
>I guess the style with intermixed C code is a bit uncommon in our
>assembly, but as long as it doesn't affect the overall code style I guess
>we can keep it.
I needed it to track where I was whilst writing the code & if I ever
need to change it I'll be lost without it - so I, at least, rate it as
valuable and in line3 where I am very tight on registers it was
invaluable for keeping track of what referred to what.
>> +ldr q31, [x1, w4, SXTW]
>> +ldr q30, [x1, w3, SXTW]
>> +ldr q29, [x1, w6, SXTW]
>> +ldr q28, [x1, w5, SXTW]
>
>Don't use shouty uppercase SXTW here
Will change.
>> +
>> +uaddl v20.8h, v31.8b, v30.8b
>> +uaddl2 v21.8h, v31.16b, v30.16b
>> +
>> +UMULL4K v2, v3, v4, v5, v20, v21, v0.h[6]
>> +
>> +uaddl v20.8h, v29.8b, v28.8b
>> +uaddl2 v21.8h, v29.16b, v28.16b
>> +
>> +UMLSL4K v2, v3, v4, v5, v20, v21, v0.h[7]
>> +
>> +//dst[0] = av_clip(interpol, 0, clip_max);
>> +SQSHRUNNv2, v2, v3, v4, v5, 13
>> +str q2, [x0], #16
>> +
>> +//dst++;
>> +//cur++;
>> +//}
>> +
>> +subsw2, w2, #16
>> +add x1, x1, #16
>
>For in-order cores, it might be good to update these variables sometime
>sooner, e.g. before the str instruction. But such scheduling breaks your
>mapping between neat C code and assembly.
I take your point but there is at least 1 instruction between set and
use which is normally enough.
I did my benching on a Pi4 and found, to my surprise, that in most cases
reordering instructions to interleavse operations made life worse and
seeing as Pi4 is my target platform I stopped trying to do that and
stuck with code that was easier to read! (Also filter_intra seems to be
much more memory b/w limited than code limited on a Pi4.)
JC
>// Martin
>
>___
>ffmpeg-devel mailing list
Re: [FFmpeg-devel] [PATCH 02/15] avfilter/vf_bwdif: Add common macros and consts for aarch64 neon
On Sun, 2 Jul 2023 00:35:14 +0300 (EEST), you wrote:
>On Thu, 29 Jun 2023, John Cox wrote:
>
>> Add macros for dual scalar half->single multiply and accumulate
>> Add macro for shift, saturate and shorten single to byte
>> Add filter constants
>>
>> Signed-off-by: John Cox
>> ---
>> libavfilter/aarch64/vf_bwdif_neon.S | 46 +
>> 1 file changed, 46 insertions(+)
>>
>> diff --git a/libavfilter/aarch64/vf_bwdif_neon.S
>> b/libavfilter/aarch64/vf_bwdif_neon.S
>> index 639ab22998..a8f0ed525a 100644
>> --- a/libavfilter/aarch64/vf_bwdif_neon.S
>> +++ b/libavfilter/aarch64/vf_bwdif_neon.S
>> @@ -23,3 +23,49 @@
>>
>> #include "libavutil/aarch64/asm.S"
>>
>> +.macro SQSHRUNN b, s0, s1, s2, s3, n
>> +sqshrun \s0\().4h, \s0\().4s, #\n - 8
>> +sqshrun2\s0\().8h, \s1\().4s, #\n - 8
>> +sqshrun \s1\().4h, \s2\().4s, #\n - 8
>> +sqshrun2\s1\().8h, \s3\().4s, #\n - 8
>> +uzp2\b\().16b, \s0\().16b, \s1\().16b
>> +.endm
>> +
>> +.macro SMULL4K a0, a1, a2, a3, s0, s1, k
>> +smull \a0\().4s, \s0\().4h, \k
>> +smull2 \a1\().4s, \s0\().8h, \k
>> +smull \a2\().4s, \s1\().4h, \k
>> +smull2 \a3\().4s, \s1\().8h, \k
>> +.endm
>> +
>> +.macro UMULL4K a0, a1, a2, a3, s0, s1, k
>> +umull \a0\().4s, \s0\().4h, \k
>> +umull2 \a1\().4s, \s0\().8h, \k
>> +umull \a2\().4s, \s1\().4h, \k
>> +umull2 \a3\().4s, \s1\().8h, \k
>> +.endm
>> +
>> +.macro UMLAL4K a0, a1, a2, a3, s0, s1, k
>> +umlal \a0\().4s, \s0\().4h, \k
>> +umlal2 \a1\().4s, \s0\().8h, \k
>> +umlal \a2\().4s, \s1\().4h, \k
>> +umlal2 \a3\().4s, \s1\().8h, \k
>> +.endm
>> +
>> +.macro UMLSL4K a0, a1, a2, a3, s0, s1, k
>> +umlsl \a0\().4s, \s0\().4h, \k
>> +umlsl2 \a1\().4s, \s0\().8h, \k
>> +umlsl \a2\().4s, \s1\().4h, \k
>> +umlsl2 \a3\().4s, \s1\().8h, \k
>> +.endm
>> +
>> +// static const uint16_t coef_lf[2] = { 4309, 213 };
>> +// static const uint16_t coef_hf[3] = { 5570, 3801, 1016 };
>> +// static const uint16_t coef_sp[2] = { 5077, 981 };
>> +
>> +.align 16
>
>Note that .align for arm is power of two; this triggers a 2^16 byte
>alignment here, which certainly isn't intended.
Yikes! I'll swap that for a .balign now I've looked that up
>But in general, the usual way of defining constants is with a
>const/endconst block, which places them in the right rdata section instead
>of in the text section. But that then requires you to use a movrel macro
>for accessing the data, instead of a plain ldr instruction.
Yeah - arm has a history of mixing text & const - I went with the
simpler code. Is this a deal breaker or can I leave it as is?
JC
>> +coeffs:
>> +.hword 4309 * 4, 213 * 4 // lf[0]*4 = v0.h[0]
>> +.hword 5570, 3801, 1016, -3801 // hf[0] = v0.h[2],
>> -hf[1] = v0.h[5]
>> +.hword 5077, 981 // sp[0] = v0.h[6]
>> +
>> --
>
>
>// 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 00/15] avfilter/vf_bwdif: Add aarch64 neon functions
Hi >On Thu, 29 Jun 2023, John Cox wrote: > >> Also adds a filter_line3 method which on aarch64 neon yields approx 30% >> speedup over 2xfilter_line and a memcpy >> >> John Cox (15): >> avfilter/vf_bwdif: Add outline for aarch neon functions >> avfilter/vf_bwdif: Add common macros and consts for aarch64 neon >> avfilter/vf_bwdif: Export C filter_intra >> avfilter/vf_bwdif: Add neon for filter_intra >> tests/checkasm: Add test for vf_bwdif filter_intra >> avfilter/vf_bwdif: Add clip and spatial macros for aarch64 neon >> avfilter/vf_bwdif: Export C filter_edge >> avfilter/vf_bwdif: Add neon for filter_edge >> tests/checkasm: Add test for vf_bwdif filter_edge >> avfilter/vf_bwdif: Export C filter_line >> avfilter/vf_bwdif: Add neon for filter_line >> avfilter/vf_bwdif: Add a filter_line3 method for optimisation >> avfilter/vf_bwdif: Add neon for filter_line3 >> tests/checkasm: Add test for vf_bwdif filter_line3 >> avfilter/vf_bwdif: Block filter slices into a multiple of 4 lines > >It's nice to have this split up in small easily checkable patches, but >this is perhaps a bit more finegrained than what's usual. But I guess >that's ok... I normally find that people ask me to split patches so I though I'd cut stuff down to the minimum plausible unit. I'm more than happy to coalesce stuff if wanted. JC >I'll comment on the patches that need commenting on. > >// Martin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] cbs_h266: fix typo for ols_mode_idc == 2
--- libavcodec/cbs_h266_syntax_template.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/cbs_h266_syntax_template.c b/libavcodec/cbs_h266_syntax_template.c index f1cd45f815..ae44565a54 100644 --- a/libavcodec/cbs_h266_syntax_template.c +++ b/libavcodec/cbs_h266_syntax_template.c @@ -712,7 +712,7 @@ static int FUNC(vps) (CodedBitstreamContext *ctx, RWContext *rw, } if (ols_mode_idc == 4 || ols_mode_idc == 0 || ols_mode_idc == 1) total_num_olss = current->vps_max_layers_minus1 + 1; -else if (ols_mode_idc = 2) +else if (ols_mode_idc == 2) total_num_olss = current->vps_num_output_layer_sets_minus2 + 2; else av_log(ctx->log_ctx, AV_LOG_ERROR, -- 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] cbs_h266: fix sign for pps_xxx_qp_offset_list
---
libavcodec/cbs_h266.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_h266.h b/libavcodec/cbs_h266.h
index 9e823919af..e33d08a0f5 100644
--- a/libavcodec/cbs_h266.h
+++ b/libavcodec/cbs_h266.h
@@ -520,9 +520,9 @@ typedef struct H266RawPPS {
uint8_t pps_slice_chroma_qp_offsets_present_flag;
uint8_t pps_cu_chroma_qp_offset_list_enabled_flag;
uint8_t pps_chroma_qp_offset_list_len_minus1;
-uint8_t pps_cb_qp_offset_list[6];
-uint8_t pps_cr_qp_offset_list[6];
-uint8_t pps_joint_cbcr_qp_offset_list[6];
+int8_t pps_cb_qp_offset_list[6];
+int8_t pps_cr_qp_offset_list[6];
+int8_t pps_joint_cbcr_qp_offset_list[6];
uint8_t pps_deblocking_filter_control_present_flag;
uint8_t pps_deblocking_filter_override_enabled_flag;
uint8_t pps_deblocking_filter_disabled_flag;
--
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".
