[FFmpeg-devel] [PATCH v9 0/3] Re-commit for davs2 api change.
hwren (3): lavc: add avs2 parser lavf: add avs2 fourcc lavc,doc,configure: add avs2 video decoder wrapper Changelog| 1 + configure| 4 ++ doc/decoders.texi| 6 ++ doc/general.texi | 14 libavcodec/Makefile | 2 + libavcodec/allcodecs.c | 1 + libavcodec/avcodec.h | 1 + libavcodec/avs2_parser.c | 95 + libavcodec/codec_desc.c | 7 ++ libavcodec/libdavs2.c| 177 +++ libavcodec/parser.c | 1 + libavcodec/version.h | 4 +- libavformat/riff.c | 1 + 13 files changed, 312 insertions(+), 2 deletions(-) create mode 100644 libavcodec/avs2_parser.c create mode 100644 libavcodec/libdavs2.c -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v9 1/3] lavc: add avs2 parser
Signed-off-by: hwren
---
libavcodec/Makefile | 1 +
libavcodec/avcodec.h | 1 +
libavcodec/avs2_parser.c | 95
libavcodec/codec_desc.c | 7
libavcodec/parser.c | 1 +
libavcodec/version.h | 4 +-
6 files changed, 107 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/avs2_parser.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3ab071a..6b6d6de 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -994,6 +994,7 @@ OBJS-$(CONFIG_AAC_PARSER) += aac_parser.o
aac_ac3_parser.o \
mpeg4audio.o
OBJS-$(CONFIG_AC3_PARSER) += ac3tab.o aac_ac3_parser.o
OBJS-$(CONFIG_ADX_PARSER) += adx_parser.o adx.o
+OBJS-$(CONFIG_AVS2_PARSER) += avs2_parser.o
OBJS-$(CONFIG_BMP_PARSER) += bmp_parser.o
OBJS-$(CONFIG_CAVSVIDEO_PARSER)+= cavs_parser.o
OBJS-$(CONFIG_COOK_PARSER) += cook_parser.o
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c90166d..1ac9092 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -409,6 +409,7 @@ enum AVCodecID {
AV_CODEC_ID_DXV,
AV_CODEC_ID_SCREENPRESSO,
AV_CODEC_ID_RSCC,
+AV_CODEC_ID_AVS2,
AV_CODEC_ID_Y41P = 0x8000,
AV_CODEC_ID_AVRP,
diff --git a/libavcodec/avs2_parser.c b/libavcodec/avs2_parser.c
new file mode 100644
index 000..163b297
--- /dev/null
+++ b/libavcodec/avs2_parser.c
@@ -0,0 +1,95 @@
+/*
+ * AVS2/IEEE 1857.4 video parser.
+ * Copyright (c) 2018 Huiwen Ren
+ *
+ * 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 "parser.h"
+
+#define SLICE_MAX_START_CODE0x01af
+
+#define ISPIC(x) ((x) == 0xB3 || (x) == 0xB6)
+#define ISUNIT(x) ((x) == 0xB0 || (x) == 0xB1 || (x) == 0xB2 || ISPIC(x))
+
+static int avs2_find_frame_end(ParseContext *pc, const uint8_t *buf, int
buf_size)
+{
+int pic_found = pc->frame_start_found;
+uint32_t state = pc->state;
+int cur = 0;
+
+if (!pic_found) {
+for (; cur < buf_size; ++cur) {
+state = (state<<8) | buf[cur];
+if (ISUNIT(buf[cur])){
+++cur;
+pic_found = 1;
+break;
+}
+}
+}
+
+if (pic_found) {
+if (!buf_size)
+return END_NOT_FOUND;
+for (; cur < buf_size; ++cur) {
+state = (state << 8) | buf[cur];
+if ((state & 0xFF00) == 0x100 && state > SLICE_MAX_START_CODE)
{
+pc->frame_start_found = 0;
+pc->state = -1;
+return cur - 3;
+}
+}
+}
+
+pc->frame_start_found = pic_found;
+pc->state = state;
+
+return END_NOT_FOUND;
+}
+
+static int avs2_parse(AVCodecParserContext *s, AVCodecContext *avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+ParseContext *pc = s->priv_data;
+int next;
+
+if (s->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
+next = avs2_find_frame_end(pc, buf, buf_size);
+if (ff_combine_frame(pc, next, &buf, &buf_size) < 0) {
+*poutbuf = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
+}
+
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+
+return next;
+}
+
+AVCodecParser ff_avs2_parser = {
+.codec_ids = { AV_CODEC_ID_AVS2 },
+.priv_data_size = sizeof(ParseContext),
+.parser_parse = avs2_parse,
+.parser_close = ff_parse_close,
+.split = ff_mpeg4video_split,
+};
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 36e9a9b..c0ed4d4 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1395,6 +1395,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.props = AV_CODEC_PROP_LOSSLESS,
},
{
+.id= AV_CODEC_ID_AVS2,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "avs2",
+.long_name = NULL_IF_CONFIG_SMALL("AVS2/IEEE 1857.4"),
+.props = AV_CODEC_PROP_LOSSY,
+},
+{
.id= AV_CODEC_ID_Y41P,
.type
[FFmpeg-devel] [PATCH v9 3/3] lavc, doc, configure: add avs2 video decoder wrapper
Signed-off-by: hwren
---
Changelog | 1 +
configure | 4 ++
doc/decoders.texi | 6 ++
doc/general.texi | 14
libavcodec/Makefile| 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/libdavs2.c | 177 +
7 files changed, 204 insertions(+)
create mode 100644 libavcodec/libdavs2.c
diff --git a/Changelog b/Changelog
index d8e2811..ec65f43 100644
--- a/Changelog
+++ b/Changelog
@@ -13,6 +13,7 @@ version :
- adeclip filter
- libtensorflow backend for DNN based filters like srcnn
- vc1 decoder is now bit-exact
+- AVS2 video decoder via libdavs2
version 4.0:
diff --git a/configure b/configure
index 0e8e8a6..845b13b 100755
--- a/configure
+++ b/configure
@@ -226,6 +226,7 @@ External library support:
--enable-libcelt enable CELT decoding via libcelt [no]
--enable-libcdio enable audio CD grabbing with libcdio [no]
--enable-libcodec2 enable codec2 en/decoding using libcodec2 [no]
+ --enable-libdavs2enable AVS2 decoding via libdavs2 [no]
--enable-libdc1394 enable IIDC-1394 grabbing using libdc1394
and libraw1394 [no]
--enable-libfdk-aac enable AAC de/encoding via libfdk-aac [no]
@@ -1638,6 +1639,7 @@ EXTERNAL_LIBRARY_GPL_LIST="
avisynth
frei0r
libcdio
+libdavs2
librubberband
libvidstab
libx264
@@ -3048,6 +3050,7 @@ libaom_av1_encoder_deps="libaom"
libcelt_decoder_deps="libcelt"
libcodec2_decoder_deps="libcodec2"
libcodec2_encoder_deps="libcodec2"
+libdavs2_decoder_deps="libdavs2"
libfdk_aac_decoder_deps="libfdk_aac"
libfdk_aac_encoder_deps="libfdk_aac"
libfdk_aac_encoder_select="audio_frame_queue"
@@ -6001,6 +6004,7 @@ enabled libcelt && require libcelt celt/celt.h
celt_decode -lcelt0 &&
die "ERROR: libcelt must be installed and
version must be >= 0.11.0."; }
enabled libcaca && require_pkg_config libcaca caca caca.h
caca_create_canvas
enabled libcodec2 && require libcodec2 codec2/codec2.h codec2_create
-lcodec2
+enabled libdavs2 && require_pkg_config libdavs2 "davs2 >= 1.5.115"
davs2.h davs2_decoder_open
enabled libdc1394 && require_pkg_config libdc1394 libdc1394-2
dc1394/dc1394.h dc1394_new
enabled libdrm&& require_pkg_config libdrm libdrm xf86drm.h
drmGetVersion
enabled libfdk_aac&& { check_pkg_config libfdk_aac fdk-aac
"fdk-aac/aacenc_lib.h" aacEncOpen ||
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 8f07bc1..9439b7b 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -47,6 +47,12 @@ top-field-first is assumed
@end table
+@section libdavs2
+
+AVS2/IEEE 1857.4 video decoder wrapper.
+
+This decoder allows libavcodec to decode AVS2 streams with davs2 library.
+
@c man end VIDEO DECODERS
@chapter Audio Decoders
diff --git a/doc/general.texi b/doc/general.texi
index 8c3a04b..cd725bb 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -17,6 +17,20 @@ for more formats. None of them are used by default, their
use has to be
explicitly requested by passing the appropriate flags to
@command{./configure}.
+@section libdavs2
+
+FFmpeg can make use of the davs2 library for AVS2/IEEE 1857.4 video decoding.
+
+Go to @url{https://github.com/pkuvcl/davs2} and follow the instructions for
+installing the library. Then pass @code{--enable-libdavs2} to configure to
+enable it.
+
+@float NOTE
+libdavs2 is under the GNU Public License Version 2 or later
+(see @url{http://www.gnu.org/licenses/old-licenses/gpl-2.0.html} for
+details), you must upgrade FFmpeg's license to GPL in order to use it.
+@end float
+
@section Alliance for Open Media libaom
FFmpeg can make use of the libaom library for AV1 decoding.
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6b6d6de..5135b97 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -944,6 +944,7 @@ OBJS-$(CONFIG_LIBAOM_AV1_ENCODER) += libaomenc.o
OBJS-$(CONFIG_LIBCELT_DECODER)+= libcelt_dec.o
OBJS-$(CONFIG_LIBCODEC2_DECODER) += libcodec2.o codec2utils.o
OBJS-$(CONFIG_LIBCODEC2_ENCODER) += libcodec2.o codec2utils.o
+OBJS-$(CONFIG_LIBDAVS2_DECODER) += libdavs2.o
OBJS-$(CONFIG_LIBFDK_AAC_DECODER) += libfdk-aacdec.o
OBJS-$(CONFIG_LIBFDK_AAC_ENCODER) += libfdk-aacenc.o
OBJS-$(CONFIG_LIBGSM_DECODER) += libgsmdec.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 90d170b..a59b601 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -667,6 +667,7 @@ extern AVCodec ff_libaom_av1_encoder;
extern AVCodec ff_libcelt_decoder;
extern AVCodec ff_libcodec2_encoder;
extern AVCodec ff_libcodec2_decoder;
+extern AVCodec ff_libdavs2_decoder;
extern AVCodec ff_libfdk_aac_encoder;
extern AVCodec ff_libfdk_aac_decoder;
extern AVCodec ff_libgsm_encoder;
diff --git a/libavcodec/libdavs2.c b/libavcodec/libda
[FFmpeg-devel] [PATCH v9 2/3] lavf: add avs2 fourcc
Signed-off-by: hwren
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 8911725..4153372 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -369,6 +369,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ AV_CODEC_ID_ZMBV, MKTAG('Z', 'M', 'B', 'V') },
{ AV_CODEC_ID_KMVC, MKTAG('K', 'M', 'V', 'C') },
{ AV_CODEC_ID_CAVS, MKTAG('C', 'A', 'V', 'S') },
+{ AV_CODEC_ID_AVS2, MKTAG('A', 'V', 'S', '2') },
{ AV_CODEC_ID_JPEG2000, MKTAG('m', 'j', 'p', '2') },
{ AV_CODEC_ID_JPEG2000, MKTAG('M', 'J', '2', 'C') },
{ AV_CODEC_ID_JPEG2000, MKTAG('L', 'J', '2', 'C') },
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3][GSOC] avfilter: added colorconstancy
On 07/16/2018 02:55 AM, Michael Niedermayer wrote: On Sun, Jul 15, 2018 at 09:13:04PM +0200, Mina wrote: Hi, This patch introduces Grey-Edge algorithm as part of the Color Constancy Filter project in GSOC. V3 changes: - corrected typo in documentation - corrected wrong value in documentation - added link to algorithm research paper in documentation - returned EINVAL and log error when sigma = 0 && difford > 0 instead of assert Best regards, Mina Sami Changelog |1 MAINTAINERS |1 doc/filters.texi| 39 ++ libavfilter/Makefile|1 libavfilter/allfilters.c|1 libavfilter/vf_colorconstancy.c | 758 6 files changed, 801 insertions(+) 470a6bcd3455fa6802ef290f438632a0b1e0ab6f 0001-avfilter-added-colorconstancy.patch From 52a0057eda8bf5147b53c9d71089d944ebaa759c Mon Sep 17 00:00:00 2001 From: Mina Date: Sun, 15 Jul 2018 20:59:52 +0200 Subject: [PATCH] avfilter: added colorconstancy breaks "make doc/ffprobe-all.html" HTMLdoc/ffprobe-all.html doc/filters.texi:9966: @subsection seen before @end table doc/filters.texi:9968: @item outside of table or list doc/filters.texi:9973: unmatched `@end itemize' doc/filters.texi:9975: @item outside of table or list doc/filters.texi:9980: unmatched `@end itemize' make: *** [doc/ffprobe-all.html] Error 1 [...] Hi, thanks for feedback. Fixed now. Any more edits to be added to v4? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize vp8 decoding in vp8dsp.
> > > > Is there anyone reviewing my patch? I sent 9 patchs about 20 days ago, but > > only one patch received reply at June 14. > > Theres a maintainer listed for mips in MAINTAINERs > he should review the patches. If he has no time then someone else should > maybe help him > Also it may make sense to split maintainership of the 2 MIPS implementations > if that would make reviews work better but it still requires someone to do > the review. > > I dont know mips asm well enough to do a optimal review Thank you very much for your reply. I have received an email from mips mantainer, he said he is no longer part of mips. what a pity. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mov: only set handler_name from mdia->hdlr
Plan to push tonight. On 14-07-2018 02:15 PM, Gyan Doshi wrote: Date: Sat, 14 Jul 2018 13:59:51 +0530 Subject: [PATCH] avformat/mov: only set handler_name from mdia->hdlr 6 FATE references updated. Fixes #7104 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Testing releases (fate)
Hi all Just wanted to remind everyone who submits fate tests to fate.ffmpeg.org that testing releases is also a good idea. It feels like iam the only one testing release/2.8 for example when i look at http://fatebeta.ffmpeg.org/v2.8 thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] fate: add more vc2 encoder tests
From: James Darnley --- Michael, can you test this for the same failure you saw last time? tests/fate/vcodec.mak | 24 tests/ref/vsynth/vsynth1-vc2-t5_3 | 4 tests/ref/vsynth/vsynth1-vc2-thaar | 4 tests/ref/vsynth/vsynth2-vc2-t5_3 | 4 tests/ref/vsynth/vsynth2-vc2-thaar | 4 tests/ref/vsynth/vsynth_lena-vc2-t5_3 | 4 tests/ref/vsynth/vsynth_lena-vc2-thaar | 4 7 files changed, 40 insertions(+), 8 deletions(-) create mode 100644 tests/ref/vsynth/vsynth1-vc2-t5_3 create mode 100644 tests/ref/vsynth/vsynth1-vc2-thaar create mode 100644 tests/ref/vsynth/vsynth2-vc2-t5_3 create mode 100644 tests/ref/vsynth/vsynth2-vc2-thaar create mode 100644 tests/ref/vsynth/vsynth_lena-vc2-t5_3 create mode 100644 tests/ref/vsynth/vsynth_lena-vc2-thaar diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak index bbcf25d72a..da6da9e09b 100644 --- a/tests/fate/vcodec.mak +++ b/tests/fate/vcodec.mak @@ -38,17 +38,25 @@ FATE_VCODEC-$(call ENCDEC, DNXHD, DNXHD) += dnxhd-720p \ FATE_VCODEC-$(call ENCDEC, VC2 DIRAC, MOV) += vc2-420p vc2-420p10 vc2-420p12 \ vc2-422p vc2-422p10 vc2-422p12 \ - vc2-444p vc2-444p10 vc2-444p12 -fate-vsynth1-vc2-%: FMT = mov -fate-vsynth1-vc2-%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth1-vc2-%=%) \ + vc2-444p vc2-444p10 vc2-444p12 \ + vc2-thaar vc2-t5_3 +fate-vsynth1-vc2-4%: FMT = mov +fate-vsynth1-vc2-4%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth1-vc2-%=%) \ -c:v vc2 -frames 5 -strict -1 -fate-vsynth2-vc2-%: FMT = mov -fate-vsynth2-vc2-%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth2-vc2-%=%) \ +fate-vsynth2-vc2-4%: FMT = mov +fate-vsynth2-vc2-4%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth2-vc2-%=%) \ -c:v vc2 -frames 5 -strict -1 -fate-vsynth_lena-vc2-%: FMT = mov -fate-vsynth_lena-vc2-%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth_lena-vc2-%=%) \ +fate-vsynth_lena-vc2-4%: FMT = mov +fate-vsynth_lena-vc2-4%: ENCOPTS = -pix_fmt yuv$(@:fate-vsynth_lena-vc2-%=%) \ -c:v vc2 -frames 5 -strict -1 +fate-vsynth1-vc2-t%: FMT = mov +fate-vsynth1-vc2-t%: ENCOPTS = -pix_fmt yuv422p10 -c:v vc2 -frames 5 -strict -1 -wavelet_type $(@:fate-vsynth1-vc2-t%=%) +fate-vsynth2-vc2-t%: FMT = mov +fate-vsynth2-vc2-t%: ENCOPTS = -pix_fmt yuv422p10 -c:v vc2 -frames 5 -strict -1 -wavelet_type $(@:fate-vsynth2-vc2-t%=%) +fate-vsynth_lena-vc2-t%: FMT = mov +fate-vsynth_lena-vc2-t%: ENCOPTS = -pix_fmt yuv422p10 -c:v vc2 -frames 5 -strict -1 -wavelet_type $(@:fate-vsynth_lena-vc2-t%=%) + fate-vsynth%-dnxhd-720p: ENCOPTS = -s hd720 -b 90M \ -pix_fmt yuv422p -frames 5 -qmax 8 fate-vsynth%-dnxhd-720p: FMT = dnxhd @@ -434,7 +442,7 @@ FATE_VSYNTH_LENA = $(FATE_VCODEC:%=fate-vsynth_lena-%) RESIZE_OFF = dnxhd-720p dnxhd-720p-rd dnxhd-720p-10bit dnxhd-1080i \ dv dv-411 dv-50 avui snow snow-hpel snow-ll vc2-420p \ vc2-420p10 vc2-420p12 vc2-422p vc2-422p10 vc2-422p12 \ - vc2-444p vc2-444p10 vc2-444p12 + vc2-444p vc2-444p10 vc2-444p12 vc2-thaar vc2-t5_3 # Incorrect parameters - usually size or color format restrictions INC_PAR_OFF = cinepak h261 h261-trellis h263 h263p h263-obmc msvideo1 \ roqvideo rv10 rv20 y41p qtrlegray diff --git a/tests/ref/vsynth/vsynth1-vc2-t5_3 b/tests/ref/vsynth/vsynth1-vc2-t5_3 new file mode 100644 index 00..543f632c23 --- /dev/null +++ b/tests/ref/vsynth/vsynth1-vc2-t5_3 @@ -0,0 +1,4 @@ +a5c80a091e7c3021ab9d5b854b4c653f *tests/data/fate/vsynth1-vc2-t5_3.mov +1604316 tests/data/fate/vsynth1-vc2-t5_3.mov +f35dd1c1df4726bb1d75d95e321b0698 *tests/data/fate/vsynth1-vc2-t5_3.out.rawvideo +stddev:1.88 PSNR: 42.61 MAXDIFF: 23 bytes: 7603200/ 760320 diff --git a/tests/ref/vsynth/vsynth1-vc2-thaar b/tests/ref/vsynth/vsynth1-vc2-thaar new file mode 100644 index 00..4c1f50f40d --- /dev/null +++ b/tests/ref/vsynth/vsynth1-vc2-thaar @@ -0,0 +1,4 @@ +62bcccb2981c4b79b635a0199a7fafb1 *tests/data/fate/vsynth1-vc2-thaar.mov +1717724 tests/data/fate/vsynth1-vc2-thaar.mov +f35dd1c1df4726bb1d75d95e321b0698 *tests/data/fate/vsynth1-vc2-thaar.out.rawvideo +stddev:1.88 PSNR: 42.61 MAXDIFF: 23 bytes: 7603200/ 760320 diff --git a/tests/ref/vsynth/vsynth2-vc2-t5_3 b/tests/ref/vsynth/vsynth2-vc2-t5_3 new file mode 100644 index 00..c4ac50d5a9 --- /dev/null +++ b/tests/ref/vsynth/vsynt
[FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy
Hi,
This patch introduces Grey-Edge algorithm as part of the Color
Constancy Filter project in GSOC.
V4 changes:
- Fixed error in filter.texi that resulted in breaking "make
doc/ffprobe-all.html"
Best regards,
Mina Sami
>From 7e24e01bc3a8303e4876b6a455dfc7d933efb6aa Mon Sep 17 00:00:00 2001
From: Mina
Date: Mon, 16 Jul 2018 10:20:02 +0200
Subject: [PATCH] avfilter: added colorconstancy
Signed-off-by: Mina
---
Changelog | 1 +
MAINTAINERS | 1 +
doc/filters.texi| 41 ++
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_colorconstancy.c | 758
6 files changed, 803 insertions(+)
create mode 100644 libavfilter/vf_colorconstancy.c
diff --git a/Changelog b/Changelog
index 72da5bf519..807a05dec9 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- vc1 decoder is now bit-exact
- ATRAC9 decoder
- lensfun wrapper filter
+- colorconstancy filter
version 4.0:
diff --git a/MAINTAINERS b/MAINTAINERS
index 78f450dda6..234b655cef 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -332,6 +332,7 @@ Filters:
vf_bwdif Thomas Mundt (CC )
vf_chromakey.cTimo Rothenpieler
vf_colorchannelmixer.cPaul B Mahol
+ vf_colorconstancy.c Mina Sami(CC )
vf_colorbalance.c Paul B Mahol
vf_colorkey.c Timo Rothenpieler
vf_colorlevels.c Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index 705d48e1b0..6e228f76ed 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9940,6 +9940,47 @@ gradfun=radius=8
@end itemize
+@section greyedge
+A color constancy variation filter which estimates scene illumination via grey edge algorithm
+and corrects the scene colors accordingly.
+
+See: @url{https://staff.science.uva.nl/th.gevers/pub/GeversTIP07.pdf}
+
+The filter accepts the following options:
+
+@table @option
+@item difford
+The order of differentiation to be applied on the scene. Must be chosen in the range
+[0,2] and default value is 1.
+
+@item minknorm
+The Minkowski parameter to be used for calculating the Minkowski distance. Must
+be chosen in the range [0,65535] and default value is 1. Set to 0 for getting
+max value instead of calculating Minkowski distance.
+
+@item sigma
+The standard deviation of Gaussian blur to be applied on the scene. Must be
+chosen in the range [0,1024.0] and default value = 1. Sigma can't be set to 0
+if @var{difford} is greater than 0.
+@end table
+
+@subsection Examples
+@itemize
+
+@item
+Grey Edge:
+@example
+greyedge=difford=1:minknorm=5:sigma=2
+@end example
+
+@item
+Max Edge:
+@example
+greyedge=difford=1:minknorm=0:sigma=2
+@end example
+
+@end itemize
+
@anchor{haldclut}
@section haldclut
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5d4549e24c..86b04e3efb 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -228,6 +228,7 @@ OBJS-$(CONFIG_FSPP_FILTER) += vf_fspp.o
OBJS-$(CONFIG_GBLUR_FILTER) += vf_gblur.o
OBJS-$(CONFIG_GEQ_FILTER)+= vf_geq.o
OBJS-$(CONFIG_GRADFUN_FILTER)+= vf_gradfun.o
+OBJS-$(CONFIG_GREYEDGE_FILTER) += vf_colorconstancy.o
OBJS-$(CONFIG_HALDCLUT_FILTER) += vf_lut3d.o framesync.o
OBJS-$(CONFIG_HFLIP_FILTER) += vf_hflip.o
OBJS-$(CONFIG_HISTEQ_FILTER) += vf_histeq.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 521bc53164..2d19929bdc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -217,6 +217,7 @@ extern AVFilter ff_vf_fspp;
extern AVFilter ff_vf_gblur;
extern AVFilter ff_vf_geq;
extern AVFilter ff_vf_gradfun;
+extern AVFilter ff_vf_greyedge;
extern AVFilter ff_vf_haldclut;
extern AVFilter ff_vf_hflip;
extern AVFilter ff_vf_histeq;
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
new file mode 100644
index 00..7194688dfa
--- /dev/null
+++ b/libavfilter/vf_colorconstancy.c
@@ -0,0 +1,758 @@
+/*
+ * Copyright (c) 2018 Mina Sami
+ *
+ * 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
Re: [FFmpeg-devel] [PATCH v2] fate: add more vc2 encoder tests
I'll likely be pushing a change to the MOV demuxer tonight which will change a tag, so you'll probably need to re-gen your refs. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink
Hi Marton, > > In the current implementation per-frame timecode is stored as > AV_PKT_DATA_STRINGS_METADATA side data, when AVPackets become AVFrames, the > AV_PKT_DATA_STRINGS_METADATA is automatically converted to entries in the > AVFrame->metadata AVDictionary. The dictionary key is "timecode". > > There is no "standard" way to store per-frame timecode, neither in packets, > nor in frames (other than the frame side data AV_FRAME_DATA_GOP_TIMECODE, but > that is too specific to MPEG). Using AVFrame->metadata for this is also > non-standard, but it allows us to implement the feature without worrying too > much about defining / documenting it. For what it’s worth, I’ve got timecode support implemented here where I turned the uint32 defined in libavutil/timecode.h into a new frame side data type. I’ve got the H.264 decoder extracting timecodes from SEI and creating these, which then feed it to the decklink output where they get converted into the appropriate VANC packets. Seems to be working pretty well, although still a couple of edge cases to be ironed out with interlaced content and PAFF streams. > > Also it is worth mentioning that the frame metadata is lost when encoding, so > the muxers won't have access to it, unless the encoders export it in some > way, such as packet metadata or side data (they current don't). Since for the moment I’m focused on the decoding case, I’ve changed the V210 encoder to convert the AVFrame side data into AVPacket side data (so the decklink output can get access to the data), and when I hook in the decklink capture support I will be submitting patches for the H.264 and HEVC encoders. >> >> 2) Is there any reason not to make a valid timecode track (ala >> AVMEDIA_TYPE_DATA AVStream) with timecode packets? Would that conflict with >> the side data approach currently implemented? > > I see no conflict, you might implement a timecode "track", but I don't see > why that would make your life any easier. The whole notion of supporting via a stream versus side data is a long-standing issue. It impacts not just timecodes but also stuff like closed captions, SCTE-104 triggers, and teletext. In some cases like MOV it’s carried in the container as a separate stream; in other cases like MPEG2/H.264/HEVC it’s carried in the video stream. At least for captions and timecodes the side data approach works fine in the video stream case but it’s problematic if the data is carried as side data needs to be extracted into a stream. The only way I could think of doing it was to insert a split filter on the video stream and feed both the actual video encoder and a second encoder instance which throws away the video frames and just acts on the side data to create the caption stream. And of course you have same problem in the other direction - if you receive the timecodes/captions via a stream, how to you get it into side data so it can be encoded by the video encoder. --- Devin Heitmueller - LTN Global Communications dheitmuel...@ltnglobal.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Testing releases (fate)
On 7/16/2018 7:29 AM, Michael Niedermayer wrote: > Hi all > > Just wanted to remind everyone who submits fate tests to fate.ffmpeg.org > that testing releases is also a good idea. > It feels like iam the only one testing release/2.8 for example when > i look at http://fatebeta.ffmpeg.org/v2.8 For such old releases that only a few select distros care about, we could suggest them to set up a couple fate instances, if anything of at least the kind of build they'd ultimately ship. After all, if it weren't for their LTS releases, we wouldn't even keep supporting old ffmpeg releases. They all obviously test them internally at the time of packaging, and some like Debian do it constantly, so setting up a fate instance should be feasible. If any distro maintainer is reading the list, can you look into this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
Hi Michael,
On Sat, Jul 14, 2018 at 4:01 PM Michael Niedermayer
wrote:
> On Fri, Jul 13, 2018 at 12:43:36PM +0100, Marcin Gorzel wrote:
> > Rematrixing supports up to 64 channels. However, there is only a limited
> number of channel layouts defined. Since the in/out channel count is
> obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
> channels etc.) the rematrixing fails.
> >
> > In ticket #6790 the problem has been partially addressed by applying a
> patch to swr_set_matrix() in rematrix.c:72.
> > However, a similar change must be also applied to swri_rematrix_init()
> in rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
> >
> > This patch adds the following check to the swri_rematrix_init() in
> rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36: if
> channel layout is non-zero, obtain channel count from the channel layout,
> otherwise, use channel count instead.
> >
> > It also modifies the checks in swr_set_matrix() in rematrix.c:72 to
> match the above checks. (Since
> av_get_channel_layout_nb_channels(s->user_in_ch_layout) was originally
> used, there may be preference to rely on the channel layout first (if
> available) before falling back to the user channel count).
> > ---
> > libswresample/rematrix.c | 18 --
> > libswresample/x86/rematrix_init.c | 8 ++--
> > 2 files changed, 18 insertions(+), 8 deletions(-)
> >
> > diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> > index 8227730056..8c9fbf3804 100644
> > --- a/libswresample/rematrix.c
> > +++ b/libswresample/rematrix.c
> > @@ -69,10 +69,12 @@ int swr_set_matrix(struct SwrContext *s, const
> double *matrix, int stride)
> > return AVERROR(EINVAL);
> > memset(s->matrix, 0, sizeof(s->matrix));
> > memset(s->matrix_flt, 0, sizeof(s->matrix_flt));
> > -nb_in = (s->user_in_ch_count > 0) ? s->user_in_ch_count :
> > -av_get_channel_layout_nb_channels(s->user_in_ch_layout);
> > -nb_out = (s->user_out_ch_count > 0) ? s->user_out_ch_count :
> > -av_get_channel_layout_nb_channels(s->user_out_ch_layout);
> > +nb_in = s->user_in_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->user_in_ch_layout)
> > +: s->user_in_ch_count;
> > +nb_out = s->user_out_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->user_out_ch_layout)
> > +: s->user_out_ch_count;
> > for (out = 0; out < nb_out; out++) {
> > for (in = 0; in < nb_in; in++)
> > s->matrix_flt[out][in] = s->matrix[out][in] = matrix[in];
>
> > @@ -384,8 +386,12 @@ av_cold static int auto_matrix(SwrContext *s)
> >
> > av_cold int swri_rematrix_init(SwrContext *s){
> > int i, j;
> > -int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > +int nb_in = s->in_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->in_ch_layout)
> > +: s->user_in_ch_count;
> > +int nb_out = s->out_ch_layout != 0
> > +? av_get_channel_layout_nb_channels(s->out_ch_layout)
> > +: s->user_out_ch_count;
>
> So this is the core of the change (the other hunk is a "duplicate" and one
> cosmetic)
>
Correct. I hope my corrected commit message makes it clearer now?
>
> The code after this uses C ? A : B;
> this implies that A is wrong in some cases and B is wrong in some cases
> you explained only one of these, that is that the layout is unable to
> represent some cases.
>
B can be wrong if the number of channels exceed the max. allowed value
(currently 64) in which case the re-matrixing fails with the 'invalid
parameter' error message.
As discussed earlier, I can add an error log to the ibavcodec (as a
separate patch) that will inform more clearly when the number of channels
is unsupported.
>
> 2nd question is, are these the ideal fields.
> shouldnt this use s->used_ch_count and s->out.ch_count?
>
I believe so:
s->out.ch_count is set from s-> user_out_ch_count anyway (in
swresample.c:167)
Also, I think s->used_ch_count is only used of input channel count.
These fields were also used in the original change here
.
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> "I am not trying to be anyone's saviour, I'm trying to think about the
> future and not be sad" - Elon Musk
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
--
Marcin Gorzel | Software Engineer | gor...@google.com |
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/5] Added reinterlace filter
Hello,
I have updated patch 2, it shall work now.
Thank you,
Vasile Toncu
On Mon, Jul 16, 2018 at 4:49 PM, Vasile Toncu
wrote:
> Hello,
>
> I have updated patch 2, it shall work now.
>
> Thank you,
> Vasile Toncu
>
> On Wed, May 30, 2018 at 2:00 PM, Vasile Toncu
> wrote:
>
>> Hello,
>>
>> Sorry for the late reply, I've been working on other projects.
>> Here is patch 2, which adds vf_reinterlace filter. To my understanding,
>> patch 2 and patch 3 will be merged at the same time, so there is no need to
>> add documentation for reinterlace as it will replace tinterlace.
>>
>> Thank you,
>> Vasile Toncu
>>
>
>
From a53d28294cd9ba94d8926d6ba5724e3dc0cf97e5 Mon Sep 17 00:00:00 2001
From: Vasile Toncu
Date: Mon, 16 Jul 2018 15:24:51 +0200
Subject: [PATCH] Patch 2 - Add reinterlace
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/reinterlace.h | 105
libavfilter/vf_reinterlace.c | 775 ++
libavfilter/x86/Makefile | 1 +
libavfilter/x86/vf_reinterlace_init.c | 102
6 files changed, 985 insertions(+)
create mode 100644 libavfilter/reinterlace.h
create mode 100644 libavfilter/vf_reinterlace.c
create mode 100644 libavfilter/x86/vf_reinterlace_init.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5d4549e24c..49fad08290 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -245,6 +245,7 @@ OBJS-$(CONFIG_IDET_FILTER) += vf_idet.o
OBJS-$(CONFIG_IL_FILTER) += vf_il.o
OBJS-$(CONFIG_INFLATE_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_INTERLACE_FILTER) += vf_tinterlace.o
+OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
OBJS-$(CONFIG_KERNDEINT_FILTER) += vf_kerndeint.o
OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 521bc53164..874d25e72f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -347,6 +347,7 @@ extern AVFilter ff_vf_thumbnail;
extern AVFilter ff_vf_thumbnail_cuda;
extern AVFilter ff_vf_tile;
extern AVFilter ff_vf_tinterlace;
+extern AVFilter ff_vf_reinterlace;
extern AVFilter ff_vf_tlut2;
extern AVFilter ff_vf_tmix;
extern AVFilter ff_vf_tonemap;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
new file mode 100644
index 00..b75a79d7ae
--- /dev/null
+++ b/libavfilter/reinterlace.h
@@ -0,0 +1,105 @@
+/*
+ * Copyright (c) 2017 Vasile Toncu
+ * Copyright (c) 2017 Thomas Mundt
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Reinterlace filter
+ */
+
+#ifndef AVFILTER_REINTERLACE_H
+#define AVFILTER_REINTERLACE_H
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/bswap.h"
+
+enum FilterMode {
+MODE_MERGE,
+MODE_DROP_EVEN,
+MODE_DROP_ODD,
+MODE_PAD,
+ MODE_INTERLEAVE_TOP,
+MODE_INTERLEAVE_BOTTOM,
+MODE_INTERLACE_X2,
+MODE_MERGE_X2,
+MODE_MERGE_TFF,
+MODE_MERGE_BFF,
+MODE_NB,
+ };
+
+enum FilterFlags {
+FLAG_NOTHING= 0x00,
+FLAG_VLPF = 0x01,
+FLAG_EXACT_TB = 0x02,
+FLAG_CVLPF = 0x04,
+FLAG_NB
+};
+
+typedef struct {
+const AVClass *class;
+int mode;
+int flags;
+
+AVFrame *prev_frame, *current_frame;
+int64_t current_frame_index;
+
+uint8_t *black_vec[4];
+int black_linesize[4];
+
+int skip_next_frame;
+
+void *thread_data;
+
+uint8_t bit_depth;
+
+void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
+ ptrdiff_t mref, ptrdiff_t pref, int clip_max);
+
+AVRational preout_time_base;
+
+ } ReInterlaceContext;
+
+#if CONFIG_GPL
+void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
+#endif
+
+#define OFFSET(x) offsetof(ReInterlaceContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+#define IS_ODD(value) (value & 1)
+
+typedef struct
Re: [FFmpeg-devel] [PATCH 2/5] Added reinterlace filter
Hello, I have updated patch 2, it shall work now. Thank you, Vasile Toncu On Wed, May 30, 2018 at 2:00 PM, Vasile Toncu wrote: > Hello, > > Sorry for the late reply, I've been working on other projects. > Here is patch 2, which adds vf_reinterlace filter. To my understanding, > patch 2 and patch 3 will be merged at the same time, so there is no need to > add documentation for reinterlace as it will replace tinterlace. > > Thank you, > Vasile Toncu > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/5] Renamed reinterlace to tinterlace
Hello,
I have updated patch 3, it shall work now.
Thank you,
Vasile Toncu
From 23bdcea190ccb801e3d5a0eb081fb28b17144452 Mon Sep 17 00:00:00 2001
From: Vasile Toncu
Date: Mon, 16 Jul 2018 16:13:10 +0200
Subject: [PATCH] Patch 3 - Move reinterlace to tinterlace
---
configure | 1 -
libavfilter/Makefile | 1 -
libavfilter/allfilters.c | 1 -
libavfilter/reinterlace.h | 105
libavfilter/tinterlace.h | 113 ++--
libavfilter/vf_reinterlace.c | 775
libavfilter/vf_tinterlace.c | 822 +-
libavfilter/x86/Makefile | 1 -
libavfilter/x86/vf_reinterlace_init.c | 102
libavfilter/x86/vf_tinterlace_init.c | 41 +-
10 files changed, 633 insertions(+), 1329 deletions(-)
delete mode 100644 libavfilter/reinterlace.h
delete mode 100644 libavfilter/vf_reinterlace.c
delete mode 100644 libavfilter/x86/vf_reinterlace_init.c
diff --git a/configure b/configure
index 5783407bdc..0a33a8dcb3 100755
--- a/configure
+++ b/configure
@@ -3415,7 +3415,6 @@ stereo3d_filter_deps="gpl"
subtitles_filter_deps="avformat avcodec libass"
super2xsai_filter_deps="gpl"
pixfmts_super2xsai_test_deps="super2xsai_filter"
-tinterlace_filter_deps="gpl"
tinterlace_merge_test_deps="tinterlace_filter"
tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 49fad08290..5d4549e24c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -245,7 +245,6 @@ OBJS-$(CONFIG_IDET_FILTER) += vf_idet.o
OBJS-$(CONFIG_IL_FILTER) += vf_il.o
OBJS-$(CONFIG_INFLATE_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_INTERLACE_FILTER) += vf_tinterlace.o
-OBJS-$(CONFIG_REINTERLACE_FILTER)+= vf_reinterlace.o
OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
OBJS-$(CONFIG_KERNDEINT_FILTER) += vf_kerndeint.o
OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 874d25e72f..521bc53164 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -347,7 +347,6 @@ extern AVFilter ff_vf_thumbnail;
extern AVFilter ff_vf_thumbnail_cuda;
extern AVFilter ff_vf_tile;
extern AVFilter ff_vf_tinterlace;
-extern AVFilter ff_vf_reinterlace;
extern AVFilter ff_vf_tlut2;
extern AVFilter ff_vf_tmix;
extern AVFilter ff_vf_tonemap;
diff --git a/libavfilter/reinterlace.h b/libavfilter/reinterlace.h
deleted file mode 100644
index b75a79d7ae..00
--- a/libavfilter/reinterlace.h
+++ /dev/null
@@ -1,105 +0,0 @@
-/*
- * Copyright (c) 2017 Vasile Toncu
- * Copyright (c) 2017 Thomas Mundt
- *
- * 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
- */
-
-/**
- * @file
- * Reinterlace filter
- */
-
-#ifndef AVFILTER_REINTERLACE_H
-#define AVFILTER_REINTERLACE_H
-
-#include "avfilter.h"
-#include "formats.h"
-#include "internal.h"
-#include "video.h"
-#include "libavutil/avassert.h"
-#include "libavutil/imgutils.h"
-#include "libavutil/opt.h"
-#include "libavutil/pixdesc.h"
-#include "libavutil/bswap.h"
-
-enum FilterMode {
-MODE_MERGE,
-MODE_DROP_EVEN,
-MODE_DROP_ODD,
-MODE_PAD,
- MODE_INTERLEAVE_TOP,
-MODE_INTERLEAVE_BOTTOM,
-MODE_INTERLACE_X2,
-MODE_MERGE_X2,
-MODE_MERGE_TFF,
-MODE_MERGE_BFF,
-MODE_NB,
- };
-
-enum FilterFlags {
-FLAG_NOTHING= 0x00,
-FLAG_VLPF = 0x01,
-FLAG_EXACT_TB = 0x02,
-FLAG_CVLPF = 0x04,
-FLAG_NB
-};
-
-typedef struct {
-const AVClass *class;
-int mode;
-int flags;
-
-AVFrame *prev_frame, *current_frame;
-int64_t current_frame_index;
-
-uint8_t *black_vec[4];
-int black_linesize[4];
-
-int skip_next_frame;
-
-void *thread_data;
-
-uint8_t bit_depth;
-
-void (*lowpass_line)(uint8_t *dstp, ptrdiff_t width, const uint8_t *srcp,
- ptrdiff_t mref, ptrdiff_t pref, int clip_max);
-
-AVRational preout_time_base;
-
- } ReInterlaceContext;
-
-#if CONFIG_GPL
-void ff_reinterlace_init_x86(ReInterlaceContext *reinterlace);
-#endif
-
-#define OFFSET(x) offsetof
Re: [FFmpeg-devel] [PATCH] avformat/mov: only set handler_name from mdia->hdlr
On 16-07-2018 03:34 PM, Gyan Doshi wrote: Plan to push tonight. On 14-07-2018 02:15 PM, Gyan Doshi wrote: Date: Sat, 14 Jul 2018 13:59:51 +0530 Subject: [PATCH] avformat/mov: only set handler_name from mdia->hdlr 6 FATE references updated. Fixes #7104 Pushed as 8aa6d9a8d37b365c8989d11e0d1b0e8aee493ece ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf/vf_scale_amf: AMF scaler/format converter filter implementation
> +static const enum AVPixelFormat input_pix_fmts[] = {
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_0RGB,
> +AV_PIX_FMT_BGR0,
> +AV_PIX_FMT_RGB0,
> +AV_PIX_FMT_GRAY8,
> +AV_PIX_FMT_YUV420P,
> +AV_PIX_FMT_YUYV422,
> +AV_PIX_FMT_NONE,
> +};
Do I miss it or did you forget to add RGBA?
Can you confirm that the alpha plane is really scaled?
(Unless I misunderstand, you haven't tested it.)
Hi Carl. Thanks for your feedback.
Yes, sure, alpha is also scaled in AMF
It look like I did mistake preparing patch and missed RGBA formats here.
I will update it
Thanks,
Alexander
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink
That is really interesting feedback guys. I have been thinking about things mostly in a MOV independent timecode track (or tracks) kind of way, but I know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data. Usually ffmpeg has some kind of superset of functionality for handling any one concept in order to be able to handle all the various forms and implementations. I don’t really see that for timecode though I don’t really know what that would look like either. Especially given the compromises you both pointed out. In my case it turned out that our Decklink Duo 2 was in a duplex state that caused the first few frames to get dropped and thus miss the opening of the output format timing wise. That is why it appeared to fail setting the timecode in the output container. We don’t really need that duplex mode (or the Decklink at all for that matter) so I think we are set for now. I will keep my thinking cap on about ffmpeg and timecode though. What I need my just be about adding understanding to mov.c and movenc.c for handling densely populated independent timecode tracks. Thanks, Jon > On Jul 16, 2018, at 6:32 AM, Devin Heitmueller > wrote: > > Hi Marton, > >> >> In the current implementation per-frame timecode is stored as >> AV_PKT_DATA_STRINGS_METADATA side data, when AVPackets become AVFrames, the >> AV_PKT_DATA_STRINGS_METADATA is automatically converted to entries in the >> AVFrame->metadata AVDictionary. The dictionary key is "timecode". >> >> There is no "standard" way to store per-frame timecode, neither in packets, >> nor in frames (other than the frame side data AV_FRAME_DATA_GOP_TIMECODE, >> but that is too specific to MPEG). Using AVFrame->metadata for this is also >> non-standard, but it allows us to implement the feature without worrying too >> much about defining / documenting it. > > For what it’s worth, I’ve got timecode support implemented here where I > turned the uint32 defined in libavutil/timecode.h into a new frame side data > type. I’ve got the H.264 decoder extracting timecodes from SEI and creating > these, which then feed it to the decklink output where they get converted > into the appropriate VANC packets. Seems to be working pretty well, although > still a couple of edge cases to be ironed out with interlaced content and > PAFF streams. > >> >> Also it is worth mentioning that the frame metadata is lost when encoding, >> so the muxers won't have access to it, unless the encoders export it in some >> way, such as packet metadata or side data (they current don't). > > Since for the moment I’m focused on the decoding case, I’ve changed the V210 > encoder to convert the AVFrame side data into AVPacket side data (so the > decklink output can get access to the data), and when I hook in the decklink > capture support I will be submitting patches for the H.264 and HEVC encoders. > >>> >>> 2) Is there any reason not to make a valid timecode track (ala >>> AVMEDIA_TYPE_DATA AVStream) with timecode packets? Would that conflict with >>> the side data approach currently implemented? >> >> I see no conflict, you might implement a timecode "track", but I don't see >> why that would make your life any easier. > > The whole notion of supporting via a stream versus side data is a > long-standing issue. It impacts not just timecodes but also stuff like > closed captions, SCTE-104 triggers, and teletext. In some cases like MOV > it’s carried in the container as a separate stream; in other cases like > MPEG2/H.264/HEVC it’s carried in the video stream. > > At least for captions and timecodes the side data approach works fine in the > video stream case but it’s problematic if the data is carried as side data > needs to be extracted into a stream. The only way I could think of doing it > was to insert a split filter on the video stream and feed both the actual > video encoder and a second encoder instance which throws away the video > frames and just acts on the side data to create the caption stream. > > And of course you have same problem in the other direction - if you receive > the timecodes/captions via a stream, how to you get it into side data so it > can be encoded by the video encoder. > > --- > Devin Heitmueller - LTN Global Communications > dheitmuel...@ltnglobal.com > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Limited timecode support for lavd/decklink
> On Jul 16, 2018, at 2:56 PM, Jonathan Morley wrote: > > That is really interesting feedback guys. I have been thinking about things > mostly in a MOV independent timecode track (or tracks) kind of way, but I > know OMF, MXF, AAF, etc handle it more analogously to packet/frame side data. > > Usually ffmpeg has some kind of superset of functionality for handling any > one concept in order to be able to handle all the various forms and > implementations. I don’t really see that for timecode though I don’t really > know what that would look like either. Especially given the compromises you > both pointed out. > > In my case it turned out that our Decklink Duo 2 was in a duplex state that > caused the first few frames to get dropped and thus miss the opening of the > output format timing wise. That is why it appeared to fail setting the > timecode in the output container. We don’t really need that duplex mode (or > the Decklink at all for that matter) so I think we are set for now. I’ve run into this in my decklink libavdevice capture code for a number of other VANC types that result in streams having to be created (e.g. SMPTE 2038 and SCTE-104). The way I approached the problem was to add an option to the demux to *always* create the stream rather than relying on the detecting the presence of the data during the probing phase. This helps in the case where a few frames may be thrown away, as well as the case where actual data is not necessarily always present (such as SCTE-104 triggers). Devin ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libswresample: Use channel count if channel layout is undefined
On Mon, Jul 16, 2018 at 03:37:15PM +0100, Marcin Gorzel wrote:
> Hi Michael,
>
> On Sat, Jul 14, 2018 at 4:01 PM Michael Niedermayer
> wrote:
>
> > On Fri, Jul 13, 2018 at 12:43:36PM +0100, Marcin Gorzel wrote:
> > > Rematrixing supports up to 64 channels. However, there is only a limited
> > number of channel layouts defined. Since the in/out channel count is
> > obtained from the channel layout, for undefined layouts (e.g. for 9, 10, 11
> > channels etc.) the rematrixing fails.
> > >
> > > In ticket #6790 the problem has been partially addressed by applying a
> > patch to swr_set_matrix() in rematrix.c:72.
> > > However, a similar change must be also applied to swri_rematrix_init()
> > in rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36.
> > >
> > > This patch adds the following check to the swri_rematrix_init() in
> > rematrix.c:389 and swri_rematrix_init_x86() in rematrix_init.c:36: if
> > channel layout is non-zero, obtain channel count from the channel layout,
> > otherwise, use channel count instead.
> > >
> > > It also modifies the checks in swr_set_matrix() in rematrix.c:72 to
> > match the above checks. (Since
> > av_get_channel_layout_nb_channels(s->user_in_ch_layout) was originally
> > used, there may be preference to rely on the channel layout first (if
> > available) before falling back to the user channel count).
> > > ---
> > > libswresample/rematrix.c | 18 --
> > > libswresample/x86/rematrix_init.c | 8 ++--
> > > 2 files changed, 18 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
> > > index 8227730056..8c9fbf3804 100644
> > > --- a/libswresample/rematrix.c
> > > +++ b/libswresample/rematrix.c
> > > @@ -69,10 +69,12 @@ int swr_set_matrix(struct SwrContext *s, const
> > double *matrix, int stride)
> > > return AVERROR(EINVAL);
> > > memset(s->matrix, 0, sizeof(s->matrix));
> > > memset(s->matrix_flt, 0, sizeof(s->matrix_flt));
> > > -nb_in = (s->user_in_ch_count > 0) ? s->user_in_ch_count :
> > > -av_get_channel_layout_nb_channels(s->user_in_ch_layout);
> > > -nb_out = (s->user_out_ch_count > 0) ? s->user_out_ch_count :
> > > -av_get_channel_layout_nb_channels(s->user_out_ch_layout);
> > > +nb_in = s->user_in_ch_layout != 0
> > > +? av_get_channel_layout_nb_channels(s->user_in_ch_layout)
> > > +: s->user_in_ch_count;
> > > +nb_out = s->user_out_ch_layout != 0
> > > +? av_get_channel_layout_nb_channels(s->user_out_ch_layout)
> > > +: s->user_out_ch_count;
> > > for (out = 0; out < nb_out; out++) {
> > > for (in = 0; in < nb_in; in++)
> > > s->matrix_flt[out][in] = s->matrix[out][in] = matrix[in];
> >
> > > @@ -384,8 +386,12 @@ av_cold static int auto_matrix(SwrContext *s)
> > >
> > > av_cold int swri_rematrix_init(SwrContext *s){
> > > int i, j;
> > > -int nb_in = av_get_channel_layout_nb_channels(s->in_ch_layout);
> > > -int nb_out = av_get_channel_layout_nb_channels(s->out_ch_layout);
> > > +int nb_in = s->in_ch_layout != 0
> > > +? av_get_channel_layout_nb_channels(s->in_ch_layout)
> > > +: s->user_in_ch_count;
> > > +int nb_out = s->out_ch_layout != 0
> > > +? av_get_channel_layout_nb_channels(s->out_ch_layout)
> > > +: s->user_out_ch_count;
> >
> > So this is the core of the change (the other hunk is a "duplicate" and one
> > cosmetic)
> >
>
> Correct. I hope my corrected commit message makes it clearer now?
>
>
> >
> > The code after this uses C ? A : B;
> > this implies that A is wrong in some cases and B is wrong in some cases
> > you explained only one of these, that is that the layout is unable to
> > represent some cases.
> >
>
> B can be wrong if the number of channels exceed the max. allowed value
> (currently 64)
If the number of channels exceed the maximum you should not reach this code.
nothing in your context can ever be out of range because
you never would get beyond checking the users parameters. Such check would
fail and nothing would use the parameters after that.
So you should never reach any check that could use an alternative
Which is what i meant, "why do we need a check here"
This is effectivly saying that the channel count (when the correct field is
used) in the context isnt actually containing the channel count.
I hope this makes it more clear why this change doesnt look correct to me.
> in which case the re-matrixing fails with the 'invalid
> parameter' error message.
> As discussed earlier, I can add an error log to the ibavcodec (as a
> separate patch) that will inform more clearly when the number of channels
> is unsupported.
Adding an error message where one is missing is probably a good idea.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream
> if theres a file with 5 video streams it doesnt make sense to summarize > teh file with the bitrate of 1 stream > Also the user has no indication of this change, the number is just different > theres nothing informing him that it is no longer the files bitrate I was thinking to output stats for each video/audio stream one line by another. It seems this would be a huge change to users who are not aware. Keeping the old file bitrate looks good to me. Can I extend this to output file bitrate for each output file? -- Wang Cao ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg decoder
With some (garbled) OGG data, PTS can overflow causing undefined behavior.
This patch avoids that by zeroing out PTS values greater than 2^62.
From 26a8582bc04f5bddc037ffcce99025e2f977abe0 Mon Sep 17 00:00:00 2001
From: Fredrik Hubinette
Date: Mon, 16 Jul 2018 14:54:43 -0700
Subject: [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg
decoder
---
libavformat/oggdec.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/oggdec.h b/libavformat/oggdec.h
index 4a2b6ddee8..798c74f671 100644
--- a/libavformat/oggdec.h
+++ b/libavformat/oggdec.h
@@ -162,8 +162,9 @@ ogg_gptopts (AVFormatContext * s, int i, uint64_t gp, int64_t *dts)
if (dts)
*dts = pts;
}
-if (pts > INT64_MAX && pts != AV_NOPTS_VALUE) {
+if (pts > INT64_MAX / 2 && pts != AV_NOPTS_VALUE) {
// The return type is unsigned, we thus cannot return negative pts
+// Limit the return value to 62 bits to avoid undefined behavior.
av_log(s, AV_LOG_ERROR, "invalid pts %"PRId64"\n", pts);
pts = AV_NOPTS_VALUE;
}
--
2.18.0.203.gfac676dfb9-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavfi/motion_estimation: use pixelutils API for sad.
On Sun, Jul 15, 2018 at 1:03 AM Michael Niedermayer wrote: > > On Sat, Jul > 14, 2018 at 12:04:46PM +0200, Marton Balint wrote: > > > > > > On Sat, 14 Jul 2018, Michael Niedermayer wrote: > > > > >On Fri, Jul 13, 2018 at 10:51:00AM +0200, Marton Balint wrote: > > >> > > >> > > >>On Thu, 12 Jul 2018, myp...@gmail.com wrote: > > >> > > >>>On Thu, Jul 12, 2018 at 12:43 AM Marton Balint wrote: > > > > > > > > On Wed, 11 Jul 2018, Jun Zhao wrote: > > > > >use pixelutils API for sad in motion estimation. > > > > Does it make sense to improve this code? I thought a superior and faster > > approach was a result of 2017 GSOC task: > > > > https://docs.google.com/document/d/1Hyh_rxP1KGsVkg7i7yU8Bcv92z0LIL4r-axpoKfvMFk/edit > > > > Maybe that code should be merged back, and any further optimalization > > should be done based on that code, no? > > > > Thanks, > > Marton > > > > >>>Hi, Marton: > > >>> > > >>>Yes, now I try to improve the > minterpolate, and after use perf > > >>>profiing the commands: > > >>> > > > >>>./ffmpeg -i a.ts -filter_complex > > >>>"minterpolate=mi_mode=mci:mc_mode=aobmc:vsbmc=1" -f null /dev/null > > >>>I found the hotspot is: > > >>>- get_sbad_ob > > >>>- get_sbad > > >>>- get_sad_ob > > >>>- bilateral_obmc > > >>>- set_frame_data > > >>> > > >>>So, as my plan, I will try to use sse2/avx2 > > >>>Scatter/Gather, optimized > > >>>sad function (use pixelutils API) > > >>>in get_sbad_ob / get_sbad / get_sad_ob first, for set_frame_data > > >>>case, maybe need to use Scatter/Gather SIMD instruction. > > >> > > >>That is great, all I am saying we should avoid diverging the two brances > > >>(FFmpeg branch, and GSOC 2017 branch), and try to merge back GSOC2017 if > > >>it > > >>can be done with reasonable amount of work before optimizing code, > > >>otherwise > > >>the GSOC2017 branch will rot and we will lose the result of the GSOC task. > > >> > > >>> > > >>>But if some guys have done some improve task in this case, I think > > >>>based on the pre-existing work is the better way. > > >> > > >>Michael was the mentor, maybe he can chip in on what should be done here. > > > > > >talk with the author/student who wrote the code, not me :) > > > > Well, his not active here, > > yes but last i heared from him, he was interrested in continuing this project > i think ive not heared much from him after that but i now see that there is a > small commit in his repo from 2018 so he is not completely inactive. > I think you should talk with him > > > > and the question is if his work is ready for > > mainline inclusion or not, and if he has done enough valuable work during > > GSOC that its worth working on mainlining it. > > He certainly did valuable work. Looking now at the ML, it seems the more or > less last thing on the ML was the RFC/Discussion thread about libmotion. > In that everyone wanted to dictate the design, and all that was contradicting > each other. > If you want to work on unifying this entangled bikeshed ball of conflicting > oppinions, that surely is very welcome. Important is that it ends in something > that is practical and high quality. > Personally i think the author should be given more authority in the design. > But again, please talk with the author of this code > I dont remember everything in as much detail about this ... > > also ive added him to the CC > > Thanks > > Now the minterpolate/libmotion auther didn't give a feedback or sugesstion, so I will update patch 1/2 (just add SSE2/AVX2 sad_32x32) with some perf data and hold on the patch 3 about minterpolate, any other comments? Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg.c: allow ffmpeg to output stats for each video stream
On 17-07-2018 02:38 AM, Wang Cao wrote: I was thinking to output stats for each video/audio stream one line by another. It seems this would be a huge change to users who are not aware. Keeping the old file bitrate looks good to me. Can I extend this to output file bitrate for each output file? Why not keep the current stats as is, and add an option for verbose stats? At the next major release, we can consider making them the default. Per-stream bitrate may be useful for those encoding HLS/DASH variants. Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
