Re: [FFmpeg-devel] [PATCHv2] avfilter/vf_drawtext: add optional default value to metadata function

[Tobias Rapp]

On 07.04.2016 20:45, Stefano Sabatini wrote:

On date Thursday 2016-04-07 12:32:47 +0200, Tobias Rapp encoded:

Signed-off-by: Tobias Rapp 
---
  doc/filters.texi  | 7 ++-
  libavfilter/vf_drawtext.c | 4 +++-
  2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 592fc24..3675b13 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6499,7 +6499,12 @@ The time at which the filter is running, expressed in 
the local time zone.
  It can accept an argument: a strftime() format string.

  @item metadata
-Frame metadata. It must take one argument specifying metadata key.
+Frame metadata. Takes one or two arguments.
+



+The first argument is mandatory and specifyies the metadata key.


specifies?


Fixed.


+
+The second argument is optional and specifies a default value, used when the
+metadata key is not found or empty.

  @item n, frame_num
  The frame number, starting from 0.
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 1ef3ecb..6b9af5b 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -860,6 +860,8 @@ static int func_metadata(AVFilterContext *ctx, AVBPrint *bp,

  if (e && e->value)
  av_bprintf(bp, "%s", e->value);
+else if (argc >= 2)
+av_bprintf(bp, "%s", argv[1]);
  return 0;
  }

@@ -975,7 +977,7 @@ static const struct drawtext_function {
  { "localtime", 0, 1, 'L', func_strftime },
  { "frame_num", 0, 0, 0,   func_frame_num },
  { "n", 0, 0, 0,   func_frame_num },
-{ "metadata",  1, 1, 0,   func_metadata },
+{ "metadata",  1, 2, 0,   func_metadata },
  };


LGTM, possibly with a micro bump, thanks.



Attached an updated patch, including the micro bump.
>From 9b598d06602815f40e5ade70a3921c5c90a4603e Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Thu, 7 Apr 2016 10:20:53 +0200
Subject: [PATCH] avfilter/vf_drawtext: add optional default value to metadata
 function

Signed-off-by: Tobias Rapp 
---
 doc/filters.texi  | 7 ++-
 libavfilter/version.h | 2 +-
 libavfilter/vf_drawtext.c | 4 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 82be06d..e848584 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6499,7 +6499,12 @@ The time at which the filter is running, expressed in the local time zone.
 It can accept an argument: a strftime() format string.
 
 @item metadata
-Frame metadata. It must take one argument specifying metadata key.
+Frame metadata. Takes one or two arguments.
+
+The first argument is mandatory and specifies the metadata key.
+
+The second argument is optional and specifies a default value, used when the
+metadata key is not found or empty.
 
 @item n, frame_num
 The frame number, starting from 0.
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 0dbb7e5..4cb5a2e 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -31,7 +31,7 @@
 
 #define LIBAVFILTER_VERSION_MAJOR   6
 #define LIBAVFILTER_VERSION_MINOR  41
-#define LIBAVFILTER_VERSION_MICRO 100
+#define LIBAVFILTER_VERSION_MICRO 101
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index 1ef3ecb..6b9af5b 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -860,6 +860,8 @@ static int func_metadata(AVFilterContext *ctx, AVBPrint *bp,
 
 if (e && e->value)
 av_bprintf(bp, "%s", e->value);
+else if (argc >= 2)
+av_bprintf(bp, "%s", argv[1]);
 return 0;
 }
 
@@ -975,7 +977,7 @@ static const struct drawtext_function {
 { "localtime", 0, 1, 'L', func_strftime },
 { "frame_num", 0, 0, 0,   func_frame_num },
 { "n", 0, 0, 0,   func_frame_num },
-{ "metadata",  1, 1, 0,   func_metadata },
+{ "metadata",  1, 2, 0,   func_metadata },
 };
 
 static int eval_function(AVFilterContext *ctx, AVBPrint *bp, char *fct,
-- 
1.9.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/shorten: fix decoding on the last frame

[Paul B Mahol]

Hi,

patch attached.

Fixes ticket #4712.
From e03ee9d75f0f9cb37498bd9ac613c460fadf1145 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Fri, 8 Apr 2016 10:35:11 +0200
Subject: [PATCH] avcodec/shorten: fix decoding of last frame

Previously it would be always discarded.

Signed-off-by: Paul B Mahol 
---
 libavcodec/shorten.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/shorten.c b/libavcodec/shorten.c
index 1d22a24..7973c95 100644
--- a/libavcodec/shorten.c
+++ b/libavcodec/shorten.c
@@ -543,10 +543,8 @@ static int shorten_decode_frame(AVCodecContext *avctx, void *data,
 s->got_quit_command = 1;
 break;
 }
-if (cmd == FN_BLOCKSIZE || cmd == FN_QUIT) {
-*got_frame_ptr = 0;
+if (cmd == FN_QUIT)
 break;
-}
 } else {
 /* process audio command */
 int residual_size = 0;
-- 
2.5.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] avfilter: add readvitc filter

[Tobias Rapp]

Add a filter to scan the top lines of video frames for vertical interval
timecode (VITC) information and attach it as metadata keys.

Signed-off-by: Tobias Rapp 
---
 Changelog |   1 +
 MAINTAINERS   |   1 +
 doc/filters.texi  |  26 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/version.h |   4 +-
 libavfilter/vf_readvitc.c | 249 ++
 7 files changed, 281 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_readvitc.c

diff --git a/Changelog b/Changelog
index b4a4dd7..51613d6 100644
--- a/Changelog
+++ b/Changelog
@@ -22,6 +22,7 @@ version :
 - musx demuxer
 - aix demuxer
 - remap filter
+- readvitc filter
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..d2593e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -385,6 +385,7 @@ Filters:
   vf_neighbor.c Paul B Mahol
   vf_psnr.c Paul B Mahol
   vf_random.c   Paul B Mahol
+  vf_readvitc.c Tobias Rapp (CC t.rapp at noa-archive 
dot com)
   vf_scale.cMichael Niedermayer
   vf_separatefields.c   Paul B Mahol
   vf_ssim.c Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index e848584..12a902e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10430,6 +10430,32 @@ less than @code{0}, the filter will try to use a good 
random seed on a
 best effort basis.
 @end table
 
+@section readvitc
+
+Read vertical interval timecode (VITC) information from the top lines of a
+video frame.
+
+The filter adds frame metadata key @code{lavfi.readvitc.tc_str} with the
+timecode value, if a valid timecode has been detected. Further metadata key
+@code{lavfi.readvitc.found} is set to 0/1 depending on whether
+timecode data has been found or not.
+
+This filter accepts the following options:
+
+@table @option
+@item scan_max
+Set the maximum number of lines to scan for VITC data. If the value is set to
+@code{-1} the full video frame is scanned. Default is @code{45}.
+
+@item thr_b
+Set the luma threshold for black. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.2}. The value must be smaller than @code{thr_w}.
+
+@item thr_w
+Set the luma threshold for white. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.6}. The value must be larger than @code{thr_b}.
+@end table
+
 @section remap
 
 Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3a3de48..0994d46 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -223,6 +223,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o 
dualinput.o framesync.
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
 OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
 OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b6f4a2c..d59b2d8 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -243,6 +243,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(PULLUP, pullup, vf);
 REGISTER_FILTER(QP, qp, vf);
 REGISTER_FILTER(RANDOM, random, vf);
+REGISTER_FILTER(READVITC,   readvitc,   vf);
 REGISTER_FILTER(REALTIME,   realtime,   vf);
 REGISTER_FILTER(REMAP,  remap,  vf);
 REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
diff --git a/libavfilter/version.h b/libavfilter/version.h
index 4cb5a2e..48b9d9a 100644
--- a/libavfilter/version.h
+++ b/libavfilter/version.h
@@ -30,8 +30,8 @@
 #include "libavutil/version.h"
 
 #define LIBAVFILTER_VERSION_MAJOR   6
-#define LIBAVFILTER_VERSION_MINOR  41
-#define LIBAVFILTER_VERSION_MICRO 101
+#define LIBAVFILTER_VERSION_MINOR  42
+#define LIBAVFILTER_VERSION_MICRO 100
 
 #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
LIBAVFILTER_VERSION_MINOR, \
diff --git a/libavfilter/vf_readvitc.c b/libavfilter/vf_readvitc.c
new file mode 100644
index 000..9bb7220
--- /dev/null
+++ b/libavfilter/vf_readvitc.c
@@ -0,0 +1,249 @@
+/*
+ * Copyright (c) 2016 Tobias Rapp
+ *
+ * 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 y

[FFmpeg-devel] [PATCH 2/2] fate: add readvitc filter test

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak | 10 ++
 tests/ref/fate/filter-metadata-readvitc-def |  5 +
 tests/ref/fate/filter-metadata-readvitc-thr |  5 +
 3 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/filter-metadata-readvitc-def
 create mode 100644 tests/ref/fate/filter-metadata-readvitc-thr

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index ef266c0..25294f3 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -620,6 +620,16 @@ FATE_METADATA_FILTER-$(call ALLYES, 
$(EBUR128_METADATA_DEPS)) += fate-filter-met
 fate-filter-metadata-ebur128: SRC = 
$(TARGET_SAMPLES)/filter/seq-3341-7_seq-3342-5-24bit.flac
 fate-filter-metadata-ebur128: CMD = run $(FILTER_METADATA_COMMAND) 
"amovie='$(SRC)',ebur128=metadata=1"
 
+READVITC_METADATA_DEPS = FFPROBE LAVFI_INDEV MOVIE_FILTER AVCODEC AVDEVICE \
+ AVI_DEMUXER FFVHUFF_DECODER READVITC_FILTER
+FATE_METADATA_FILTER-$(call ALLYES, $(READVITC_METADATA_DEPS)) += 
fate-filter-metadata-readvitc-def
+fate-filter-metadata-readvitc-def: SRC = 
$(TARGET_SAMPLES)/filter/sample-vitc.avi
+fate-filter-metadata-readvitc-def: CMD = run $(FILTER_METADATA_COMMAND) 
"movie='$(SRC)',readvitc"
+
+FATE_METADATA_FILTER-$(call ALLYES, $(READVITC_METADATA_DEPS)) += 
fate-filter-metadata-readvitc-thr
+fate-filter-metadata-readvitc-thr: SRC = 
$(TARGET_SAMPLES)/filter/sample-vitc.avi
+fate-filter-metadata-readvitc-thr: CMD = run $(FILTER_METADATA_COMMAND) 
"movie='$(SRC)',readvitc=thr_b=0.3:thr_w=0.5"
+
 tests/data/file4560-override2rotate0.mov: TAG = GEN
 tests/data/file4560-override2rotate0.mov: ffmpeg$(PROGSSUF)$(EXESUF) | 
tests/data
$(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
diff --git a/tests/ref/fate/filter-metadata-readvitc-def 
b/tests/ref/fate/filter-metadata-readvitc-def
new file mode 100644
index 000..8a650f1
--- /dev/null
+++ b/tests/ref/fate/filter-metadata-readvitc-def
@@ -0,0 +1,5 @@
+pkt_pts=0|tag:lavfi.readvitc.found=0
+pkt_pts=1|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:21
+pkt_pts=2|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:22
+pkt_pts=3|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:23
+pkt_pts=4|tag:lavfi.readvitc.found=0
diff --git a/tests/ref/fate/filter-metadata-readvitc-thr 
b/tests/ref/fate/filter-metadata-readvitc-thr
new file mode 100644
index 000..4086663
--- /dev/null
+++ b/tests/ref/fate/filter-metadata-readvitc-thr
@@ -0,0 +1,5 @@
+pkt_pts=0|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:20
+pkt_pts=1|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:21
+pkt_pts=2|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:22
+pkt_pts=3|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:23
+pkt_pts=4|tag:lavfi.readvitc.found=1|tag:lavfi.readvitc.tc_str=05:01:02:24
-- 
1.9.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 0/2] add readvitc filter

[Tobias Rapp]

The following patches add a filter that allows to scan video frames for VITC
lines, including FATE test.

The sample file for the FATE test can be found at:
https://cerebrum.noa-archive.com/noacloud/public.php?service=files&t=88eeb716819bba39584be03c2d1f053b
 (1.4MB)
and is assumed to be stored as $FATE_SAMPLES/filter/sample-vitc.avi

MD5SUM:150ca9d1f6283f136ce14bd7a7cf025e
SHA256SUM: ec39eeda7587536a4c90ae14288e895defa8fc64c536eeca88b34899a963d42f

Regards,
Tobias


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add readvitc filter

[Paul B Mahol]

On 4/8/16, Tobias Rapp  wrote:
> Add a filter to scan the top lines of video frames for vertical interval
> timecode (VITC) information and attach it as metadata keys.
>
> Signed-off-by: Tobias Rapp 
> ---
>  Changelog |   1 +
>  MAINTAINERS   |   1 +
>  doc/filters.texi  |  26 +
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/version.h |   4 +-
>  libavfilter/vf_readvitc.c | 249
> ++
>  7 files changed, 281 insertions(+), 2 deletions(-)
>  create mode 100644 libavfilter/vf_readvitc.c
>
> diff --git a/Changelog b/Changelog
> index b4a4dd7..51613d6 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -22,6 +22,7 @@ version :
>  - musx demuxer
>  - aix demuxer
>  - remap filter
> +- readvitc filter
>
>  version 3.0:
>  - Common Encryption (CENC) MP4 encoding and decoding support
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a993a67..d2593e5 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -385,6 +385,7 @@ Filters:
>vf_neighbor.c Paul B Mahol
>vf_psnr.c Paul B Mahol
>vf_random.c   Paul B Mahol
> +  vf_readvitc.c Tobias Rapp (CC t.rapp at
> noa-archive dot com)
>vf_scale.cMichael Niedermayer
>vf_separatefields.c   Paul B Mahol
>vf_ssim.c Paul B Mahol
> diff --git a/doc/filters.texi b/doc/filters.texi
> index e848584..12a902e 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -10430,6 +10430,32 @@ less than @code{0}, the filter will try to use a
> good random seed on a
>  best effort basis.
>  @end table
>
> +@section readvitc
> +
> +Read vertical interval timecode (VITC) information from the top lines of a
> +video frame.
> +
> +The filter adds frame metadata key @code{lavfi.readvitc.tc_str} with the
> +timecode value, if a valid timecode has been detected. Further metadata key
> +@code{lavfi.readvitc.found} is set to 0/1 depending on whether
> +timecode data has been found or not.
> +
> +This filter accepts the following options:
> +
> +@table @option
> +@item scan_max
> +Set the maximum number of lines to scan for VITC data. If the value is set
> to
> +@code{-1} the full video frame is scanned. Default is @code{45}.
> +
> +@item thr_b
> +Set the luma threshold for black. Accepts float numbers in the range
> [0.0,1.0],
> +default value is @code{0.2}. The value must be smaller than @code{thr_w}.
> +
> +@item thr_w
> +Set the luma threshold for white. Accepts float numbers in the range
> [0.0,1.0],
> +default value is @code{0.6}. The value must be larger than @code{thr_b}.
> +@end table
> +
>  @section remap
>
>  Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3a3de48..0994d46 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -223,6 +223,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   +=
> vf_psnr.o dualinput.o framesync.
>  OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
>  OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
>  OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
> +OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
>  OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
>  OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
>  OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index b6f4a2c..d59b2d8 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -243,6 +243,7 @@ void avfilter_register_all(void)
>  REGISTER_FILTER(PULLUP, pullup, vf);
>  REGISTER_FILTER(QP, qp, vf);
>  REGISTER_FILTER(RANDOM, random, vf);
> +REGISTER_FILTER(READVITC,   readvitc,   vf);
>  REGISTER_FILTER(REALTIME,   realtime,   vf);
>  REGISTER_FILTER(REMAP,  remap,  vf);
>  REGISTER_FILTER(REMOVEGRAIN,removegrain,vf);
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index 4cb5a2e..48b9d9a 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -30,8 +30,8 @@
>  #include "libavutil/version.h"
>
>  #define LIBAVFILTER_VERSION_MAJOR   6
> -#define LIBAVFILTER_VERSION_MINOR  41
> -#define LIBAVFILTER_VERSION_MICRO 101
> +#define LIBAVFILTER_VERSION_MINOR  42
> +#define LIBAVFILTER_VERSION_MICRO 100
>
>  #define LIBAVFILTER_VERSION_INT AV_VERSION_INT(LIBAVFILTER_VERSION_MAJOR, \
> LIBAVFILTER_VERSION_MINOR, \
> diff --git a/libavfilter/vf_readvitc.c b/libavfilter/vf_readvitc.c
> new file mode 100644
> index 000..9bb7220
> --- /dev/null
> +++ b/libavfilter/vf_readvitc.c
> @@ -0,0 +1,249 @@
> +/*
> + * Copyright (c) 2016 Tobia

Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Add a gsm muxer

[Michael Niedermayer]

On Tue, Apr 05, 2016 at 12:10:03PM +0200, Carl Eugen Hoyos wrote:
> On Saturday 02 April 2016 03:23:31 pm Michael Niedermayer wrote:
> > On Sat, Apr 02, 2016 at 10:29:20AM +0200, Carl Eugen Hoyos wrote:
> > > Hi!
> > >
> > > Attached is a probe function for gsm and a patch for a gsm muxer to allow
> > > testing. The file format is for example supported by sox.
> > >
> > > Please comment, Carl Eugen
> >
> > breaks fate-gif-deal somehow
> 
> Cool effect, new muxer patch attached.
> 
> Thank you, Carl Eugen

>  Makefile |1 +
>  allformats.c |2 +-
>  rawenc.c |   14 ++
>  3 files changed, 16 insertions(+), 1 deletion(-)

LGTM

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 8/8] lavf/movenc+dashenc: add automatic bitstream filtering

[Moritz Barsnick]

On Thu, Apr 07, 2016 at 19:38:09 -0500, Rodger Combs wrote:
> ---
>  libavformat/dashenc.c |  43 +++-
>  libavformat/movenc-test.c |   3 ++
>  libavformat/movenc.c  | 100 
> +++---
>  3 files changed, 121 insertions(+), 25 deletions(-)

Cool. I wasn't capable of the necessary rewrite for automatic
insertion in mov. Thanks for providing it.

While you're at it, do you have the bandwidth for proiding the same for
flvenc? I think that may be the last muxer which could make use of it.

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/8] lavf/segment: add deinit function

[Michael Niedermayer]

On Thu, Apr 07, 2016 at 07:38:05PM -0500, Rodger Combs wrote:
> ---
>  libavformat/segment.c | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)

applyg patches 1,2,3,4 leads to:

src/libavformat/segment.c: In function ‘seg_init’:
src/libavformat/segment.c:796:9: error: implicit declaration of function 
‘seg_free_context’ [-Werror=implicit-function-declaration]


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v2] avfilter: add readvitc filter

[Tobias Rapp]

On 08.04.2016 11:23, Paul B Mahol wrote:

On 4/8/16, Tobias Rapp  wrote:

Add a filter to scan the top lines of video frames for vertical interval
timecode (VITC) information and attach it as metadata keys.

Signed-off-by: Tobias Rapp 
---

>>

[...]

>>

+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pixel_fmts_eq[] = {
+AV_PIX_FMT_GRAY8,
+AV_PIX_FMT_YUV410P,
+AV_PIX_FMT_YUV411P,
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV422P,
+AV_PIX_FMT_YUV444P,


AV_PIX_FMT_YUV440P? Also J variants...


Good catch, I was lazy and just copied the function from vf_eq.c. The 
updated patch should contain all pixel formats with planar 8bit luma 
component.



+AV_PIX_FMT_NONE
+};
+AVFilterFormats *fmts_list = ff_make_format_list(pixel_fmts_eq);
+if (!fmts_list)
+return AVERROR(ENOMEM);
+return ff_set_common_formats(ctx, fmts_list);
+}
+
+static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
+{
+AVFilterContext *ctx = inlink->dst;
+AVFilterLink *outlink = ctx->outputs[0];
+ReadVitcContext *s = ctx->priv;
+int found;
+
+found = read_vitc_line(s, frame->data[0], frame->linesize[0],
inlink->w, inlink->h);
+av_dict_set(&frame->metadata, "lavfi.readvitc.found", (found ? "1" :
"0"), 0);
+if (found)
+av_dict_set(&frame->metadata, "lavfi.readvitc.tc_str",
make_vitc_tc_string(s->tcbuf, s->line_data), 0);
+
+return ff_filter_frame(outlink, frame);
+}
+
+#if CONFIG_READVITC_FILTER


Not needed.


Removed.


+
+static const AVFilterPad inputs[] = {
+{
+.name = "default",
+.type = AVMEDIA_TYPE_VIDEO,
+.filter_frame = filter_frame,
+.config_props = config_props,
+},
+{ NULL }
+};
+
+static const AVFilterPad outputs[] = {
+{
+.name = "default",
+.type = AVMEDIA_TYPE_VIDEO,
+},
+{ NULL }
+};
+
+AVFilter ff_vf_readvitc = {
+.name  = "readvitc",
+.description   = NULL_IF_CONFIG_SMALL("Read vertical interval timecode
and write it to frame metadata."),
+.priv_size = sizeof(ReadVitcContext),
+.priv_class= &readvitc_class,
+.inputs= inputs,
+.outputs   = outputs,
+.init  = init,
+.query_formats = query_formats,
+};
+
+#endif /* CONFIG_READVITC_FILTER */


Not needed.


Removed.

Thanks for the review,
Tobias
>From e145bec4bc57dc18dd3efe2d2df3976e51b79cea Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Wed, 6 Apr 2016 16:25:53 +0200
Subject: [PATCH 1/2] avfilter: add readvitc filter

Add a filter to scan the top lines of video frames for vertical interval
timecode (VITC) information and attach it as metadata keys.

Signed-off-by: Tobias Rapp 
---
 Changelog |   1 +
 MAINTAINERS   |   1 +
 doc/filters.texi  |  26 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/version.h |   4 +-
 libavfilter/vf_readvitc.c | 255 ++
 7 files changed, 287 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_readvitc.c

diff --git a/Changelog b/Changelog
index b4a4dd7..51613d6 100644
--- a/Changelog
+++ b/Changelog
@@ -22,6 +22,7 @@ version :
 - musx demuxer
 - aix demuxer
 - remap filter
+- readvitc filter
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..d2593e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -385,6 +385,7 @@ Filters:
   vf_neighbor.c Paul B Mahol
   vf_psnr.c Paul B Mahol
   vf_random.c   Paul B Mahol
+  vf_readvitc.c Tobias Rapp (CC t.rapp at noa-archive dot com)
   vf_scale.cMichael Niedermayer
   vf_separatefields.c   Paul B Mahol
   vf_ssim.c Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index e848584..12a902e 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10430,6 +10430,32 @@ less than @code{0}, the filter will try to use a good random seed on a
 best effort basis.
 @end table
 
+@section readvitc
+
+Read vertical interval timecode (VITC) information from the top lines of a
+video frame.
+
+The filter adds frame metadata key @code{lavfi.readvitc.tc_str} with the
+timecode value, if a valid timecode has been detected. Further metadata key
+@code{lavfi.readvitc.found} is set to 0/1 depending on whether
+timecode data has been found or not.
+
+This filter accepts the following options:
+
+@table @option
+@item scan_max
+Set the maximum number of lines to scan for VITC data. If the value is set to
+@code{-1} the full video frame is scanned. Default is @code{45}.
+
+@item thr_b
+Set the luma threshold for black. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.2}. The value must be smaller than @code{

[FFmpeg-devel] [PATCH] swscale/arm: add ff_hscale_8_to_15_neon

[Matthieu Bouron]

From: Matthieu Bouron 

---
 libswscale/arm/Makefile   |  6 ++--
 libswscale/arm/hscale.S   | 70 +++
 libswscale/arm/swscale.c  | 37 +++
 libswscale/swscale.c  |  2 ++
 libswscale/swscale_internal.h |  1 +
 5 files changed, 114 insertions(+), 2 deletions(-)
 create mode 100644 libswscale/arm/hscale.S
 create mode 100644 libswscale/arm/swscale.c

diff --git a/libswscale/arm/Makefile b/libswscale/arm/Makefile
index 9ccec3b..b8b0134 100644
--- a/libswscale/arm/Makefile
+++ b/libswscale/arm/Makefile
@@ -1,5 +1,7 @@
-OBJS+= arm/swscale_unscaled.o
+OBJS+= arm/swscale.o\
+   arm/swscale_unscaled.o   \
 
 NEON-OBJS   += arm/rgb2yuv_neon_32.o
 NEON-OBJS   += arm/rgb2yuv_neon_16.o
-NEON-OBJS   += arm/yuv2rgb_neon.o
+NEON-OBJS   += arm/hscale.o \
+   arm/yuv2rgb_neon.o   \
diff --git a/libswscale/arm/hscale.S b/libswscale/arm/hscale.S
new file mode 100644
index 000..d559b3d
--- /dev/null
+++ b/libswscale/arm/hscale.S
@@ -0,0 +1,70 @@
+/*
+ * Copyright (c) 2016 Clément Bœsch 
+ * Copyright (c) 2016 Matthieu Bouron 
+ *
+ * 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/arm/asm.S"
+
+function ff_hscale_8_to_15_neon, export=1
+push{r4-r12, lr}
+vpush   {q4-q7}
+ldr r4, [sp, #104] @ filter
+ldr r5, [sp, #108] @ 
filterPos
+ldr r6, [sp, #112] @ 
filterSize
+add r10, r4, r6, lsl #1@ 
filter2 = filter + filterSize * 2
+1:  ldr r8, [r5], #4   @ 
filterPos[0]
+ldr r9, [r5], #4   @ 
filterPos[1]
+vmov.s32q4, #0 @ val 
accumulator
+vmov.s32q5, #0 @ val 
accumulator
+mov r7, r6 @ 
filterSize counter
+mov r0, r3 @ srcp
+2:  add r11, r0, r8@ srcp 
+ filterPos[0]
+add r12, r0, r9@ srcp 
+ filterPos[1]
+vld1.8  d0, [r11]  @ 
srcp[filterPos[0] + {0..7}]
+vld1.8  d2, [r12]  @ 
srcp[filterPos[1] + {0..7}]
+vld1.16 {q2}, [r4]!@ load 
8x16-bit filter values
+vld1.16 {q3}, [r10]!   @ load 
8x16-bit filter values
+vmovl.u8q0, d0 @ 
unpack src values to 16-bit
+vmovl.u8q1, d2 @ 
unpack src values to 16-bit
+vmull.s16   q8, d0, d4 @ 
srcp[filterPos[0] + {0..7}] * filter[{0..7}] (part 1)
+vmull.s16   q9, d1, d5 @ 
srcp[filterPos[0] + {0..7}] * filter[{0..7}] (part 2)
+vmull.s16   q10, d2, d6@ 
srcp[filterPos[1] + {0..7}] * filter[{0..7}] (part 1)
+vmull.s16   q11, d3, d7@ 
srcp[filterPos[1] + {0..7}] * filter[{0..7}] (part 2)
+vpadd.s32   d16, d16, d17  @ 
horizontal pair adding of the 8x32-bit multiplied values into 4x32-bit (part 1)
+vpadd.s32   d17, d18, d19  @ 
horizontal pair adding of the 8x32-bit multiplied values into 4x32-bit (part 2)
+vpadd.s32   d20, d20, d21  @ 
horizontal pair adding of the 8x32-bit multiplied values into 4x32-bit (part 1)
+vpadd.s32   d21, d22, d23  @ 
horizontal pair adding of the 8x32-bit multiplied values into 4x32-bit (part 2)
+vadd.s32q4, q

Re: [FFmpeg-devel] [PATCH 1/8] lavf: add a flag to enable/disable automatic bitstream filtering

[Michael Niedermayer]

On Thu, Apr 07, 2016 at 07:38:02PM -0500, Rodger Combs wrote:
> This is mostly useful for muxers that wrap other muxers, such as dashenc
> and segment. The actual duplicated bitstream filtering is largely harmless,
> but delaying the header can cause problems when the muxer intended the header
> to be written to a separate file.
> ---
>  libavformat/avformat.h  | 1 +
>  libavformat/mux.c   | 4 ++--
>  libavformat/options_table.h | 3 ++-
>  3 files changed, 5 insertions(+), 3 deletions(-)

the check_bitstream() documentation should be updated to refer to
AVFMT_FLAG_AUTO_BSF

otherwise this LGTM

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v2] avfilter: add readvitc filter

[Carl Eugen Hoyos]

Tobias Rapp  noa-archive.com> writes:

> > AV_PIX_FMT_YUV440P? Also J variants...
> 
> Good catch, I was lazy and just copied the function from vf_eq.c. The 
> updated patch should contain all pixel formats with planar 8bit luma 
> component.

Instead of listing the formats, check for pix_fmts 
that are 8bit and planar.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/8] lavf/mux: run AVCodec::deinit if write_header fails

[Michael Niedermayer]

On Thu, Apr 07, 2016 at 07:38:03PM -0500, Rodger Combs wrote:
> ---
>  libavformat/mux.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

LGTM

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter: add readvitc filter

[Carl Eugen Hoyos]

Tobias Rapp  noa-archive.com> writes:

> +  item thr_b
> +Set the luma threshold for black. Accepts float numbers in 
> the range [0.0,1.0],
> +default value is   code{0.2}. The value must be smaller 
> than   code{thr_w}.
> +
> +  item thr_w
> +Set the luma threshold for white. Accepts float numbers in 
> the range [0.0,1.0],
> +default value is   code{0.6}. The value must be larger 
> than   code{thr_b}.

I believe it would make sense to (slightly) change this 
logic so the user can specify 0.5 both for black and 
white and would get a documented behaviour.

> +crc ^= ((line[0] >> 6) | 0x04 | (line[1] << 4));

Very minor comment: At least some of the parentheses 
should be unneeded.
(Actually all after checking again.)

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/8] lavf/mux: add avformat_init_output

[Michael Niedermayer]

On Thu, Apr 07, 2016 at 07:38:04PM -0500, Rodger Combs wrote:
> This allows a consumer to run the muxer's init function without actually
> writing the header, which is useful in chained muxers that support
> automatic bitstream filtering.
> ---
>  libavformat/avformat.h | 30 +++--
>  libavformat/internal.h | 10 +
>  libavformat/mux.c  | 59 
> +++---
>  libavformat/version.h  |  2 +-
>  4 files changed, 85 insertions(+), 16 deletions(-)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 3b41b57..908d3d1 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -616,6 +616,8 @@ typedef struct AVOutputFormat {
>   * AVStream parameters that need to be set before packets are sent.
>   * This method must not write output.
>   *
> + * Return 0 if streams were fully configured, 1 if not, negative AVERROR 
> on failure

this should use named identifers like (names just random, no preferrance
on my side ...)
#define ALL_STREAMS_CONFIGURED 0
#define NOT_ALL_STREAMS_CONFIGURED 1

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : Fix channel detection

[Carl Eugen Hoyos]

Martin Vignali  gmail.com> writes:

> -line = AV_RL32(src - 8);
> +line = (int32_t)AV_RL32(src - 8);

This change is ugly and should be unneeded.

> +channel_buffer[0] += channelLineSize * line_to_skip;
> +channel_buffer[1] += channelLineSize * line_to_skip;
> +channel_buffer[2] += channelLineSize * line_to_skip;
> +if (channel_buffer[3])
> +channel_buffer[3] += channelLineSize * line_to_skip;

> +channel_buffer[0] += channelLineSize;
> +channel_buffer[1] += channelLineSize;
> +channel_buffer[2] += channelLineSize;
> +if (channel_buffer[3])
> +channel_buffer[3] += channelLineSize;

for() loops?

> +if (s->pixel_type == EXR_HALF)
> +s->pixel_size = 2;
> +else
> +s->pixel_size = 4;
> +

Please add braces.

Feel free to ignore if you disagree.

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4 2/3] avformat/tee: Fix leaks in tee muxer when open_slave fails

[Jan Sebechlebsky]

On 04/07/2016 12:28 AM, Marton Balint wrote:


On Mon, 4 Apr 2016, sebechlebsky...@gmail.com wrote:


From: Jan Sebechlebsky 

Calling close_slave in case error is to be returned from open_slave
will free allocated resources.

Since failure can happen before bsfs array is initialized,
close_slave must check that bsfs is not NULL before accessing
tee_slave->bsfs[i] element.


I noticed a problem. tee->nb_slaves is only assigned after opening all 
slaves, so if any of the open_slave call fails, tee->nb_slaves will 
still be 0, so no resources will get freed.


On the other hand, if you move the assignment before the open_slave 
loop, you will also have to handle the case in close_slaves when 
tee_slave->avf is null, or you have to increase tee->nb_slaves 
incrementally in the loop...


Regards,
Marton
Thanks, this is another thing I overlooked when I was splitting the 
changes in 3 commits. Actually in third patch tee->nb_slaves is assigned 
before open_slave loop. I'll fix it to have stable version after each 
single patch.


Have a nice day

Jan S.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/8] lavf/segment: fix writing separate header with auto BSF

[Michael Niedermayer]

On Thu, Apr 07, 2016 at 07:38:06PM -0500, Rodger Combs wrote:
> ---
>  libavformat/segment.c | 55 
> ++-
>  1 file changed, 41 insertions(+), 14 deletions(-)

this with the previous patches seems to break:

./ffmpeg -fflags +genpts -i new_bad.vob -map 0:1 -map 0:13 -codec copy -f 
segment -segment_time 2 out-%08d.nut

https://trac.ffmpeg.org/raw-attachment/ticket/3197/new_bad.vob

after the patch the first output file is rather short

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Those who are best at talking, realize last or never when they are wrong.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v2] avfilter: add readvitc filter

[Paul B Mahol]

On 4/8/16, Carl Eugen Hoyos  wrote:
> Tobias Rapp  noa-archive.com> writes:
>
>> > AV_PIX_FMT_YUV440P? Also J variants...
>>
>> Good catch, I was lazy and just copied the function from vf_eq.c. The
>> updated patch should contain all pixel formats with planar 8bit luma
>> component.
>
> Instead of listing the formats, check for pix_fmts
> that are 8bit and planar.

Nope, bad idea.

>
> Carl Eugen
>
> ___
> 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 v4 3/3] avformat/tee: Handling slave failure in tee muxer

[Jan Sebechlebsky]

On 04/07/2016 12:37 AM, Marton Balint wrote:


On Mon, 4 Apr 2016, sebechlebsky...@gmail.com wrote:


From: Jan Sebechlebsky 

Adds per slave option 'onfail' to the tee muxer allowing an output to
fail,so other slave outputs can continue.

Signed-off-by: Jan Sebechlebsky 
---
I've just added topic to commit message title as Marton Balint 
suggested.


doc/muxers.texi   | 14 
libavformat/tee.c | 96 
+--

2 files changed, 100 insertions(+), 10 deletions(-)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 2aafbad..2d63083 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -1372,6 +1372,12 @@ Select the streams that should be mapped to 
the slave output,

specified by a stream specifier. If not specified, this defaults to
all the input streams. You may use multiple stream specifiers
separated by commas (@code{,}) e.g.: @code{a:0,v}
+
+@item onfail
+Specify behaviour on output failure. This can be set to either 
@code{abort} (which is
+default) or @code{ignore}. @code{abort} will cause whole process to 
fail in case of failure
+on this slave output. @code{ignore} will ignore failure on this 
output, so other outputs

+will continue without being affected.
@end table

@subsection Examples
@@ -1386,6 +1392,14 @@ ffmpeg -i ... -c:v libx264 -c:a mp2 -f tee 
-map 0:v -map 0:a

@end example

@item
+As above, but continue streaming even if output to local file fails
+(for example local drive fills up):
+@example
+ffmpeg -i ... -c:v libx264 -c:a mp2 -f tee -map 0:v -map 0:a
+ "[onfail=ignore]archive-20121107.mkv|[f=mpegts]udp://10.0.1.255:1234/"
+@end example
+
+@item
Use @command{ffmpeg} to encode the input, and send the output
to three different destinations. The @code{dump_extra} bitstream
filter is used to add extradata information to all the output video
diff --git a/libavformat/tee.c b/libavformat/tee.c
index d823805..50aaf9f 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -29,10 +29,20 @@

#define MAX_SLAVES 16

+typedef enum {
+ON_SLAVE_FAILURE_ABORT  = 1,
+ON_SLAVE_FAILURE_IGNORE = 2
+} SlaveFailurePolicy;
+
+#define DEFAULT_SLAVE_FAILURE_POLICY ON_SLAVE_FAILURE_ABORT
+
typedef struct {
AVFormatContext *avf;
AVBitStreamFilterContext **bsfs; ///< bitstream filters per stream

+SlaveFailurePolicy on_fail;
+unsigned char is_alive;
+
/** map from input to output streams indexes,
 * disabled output streams are set to -1 */
int *stream_map;
@@ -41,6 +51,7 @@ typedef struct {
typedef struct TeeContext {
const AVClass *class;
unsigned nb_slaves;
+unsigned nb_alive;
TeeSlave slaves[MAX_SLAVES];
} TeeContext;

@@ -135,6 +146,18 @@ end:
return ret;
}

+static inline int parse_slave_failure_policy_option(const char *opt)
+{
+if (!opt) {
+return DEFAULT_SLAVE_FAILURE_POLICY;
+} else if (!av_strcasecmp("abort", opt)) {
+return ON_SLAVE_FAILURE_ABORT;
+} else if (!av_strcasecmp("ignore", opt)) {
+return ON_SLAVE_FAILURE_IGNORE;
+}
+return 0;


Probably better, if you return AVERROR(EINVAL) in case of an invalid 
option, and check for a negative return value to detect an error, that 
is the way most functions work in ffmpeg.

I'll do that.



+}
+
static void close_slave(TeeSlave *tee_slave)
{
AVFormatContext *avf;
@@ -165,7 +188,8 @@ static void close_slaves(AVFormatContext *avf)
unsigned i;

for (i = 0; i < tee->nb_slaves; i++) {
-close_slave(&tee->slaves[i]);
+if (tee->slaves[i].is_alive)
+close_slave(&tee->slaves[i]);
}
}

@@ -175,7 +199,7 @@ static int open_slave(AVFormatContext *avf, char 
*slave, TeeSlave *tee_slave)

AVDictionary *options = NULL;
AVDictionaryEntry *entry;
char *filename;
-char *format = NULL, *select = NULL;
+char *format = NULL, *select = NULL, *on_fail = NULL;
AVFormatContext *avf2 = NULL;
AVStream *st, *st2;
int stream_count;
@@ -195,6 +219,17 @@ static int open_slave(AVFormatContext *avf, char 
*slave, TeeSlave *tee_slave)


STEAL_OPTION("f", format);
STEAL_OPTION("select", select);
+STEAL_OPTION("onfail", on_fail);
+
+tee_slave->on_fail = parse_slave_failure_policy_option(on_fail);
+if (!tee_slave->on_fail) {
+av_log(avf, AV_LOG_ERROR,
+   "Invalid onfail option value, valid options are 
'abort' and 'ignore'\n");

+ret = AVERROR(EINVAL);
+/* Set failure behaviour to abort, so invalid option error 
will not be ignored */

+tee_slave->on_fail = ON_SLAVE_FAILURE_ABORT;
+goto end;
+}

ret = avformat_alloc_output_context2(&avf2, NULL, format, filename);
if (ret < 0)
@@ -339,8 +374,11 @@ static int open_slave(AVFormatContext *avf, char 
*slave, TeeSlave *tee_slave)

}

end:
+if (ret < 0)
+close_slave(tee_slave);


I may miss something, but is this necessary here? In case of an error, 
you will call tee_process_slave_failure explictly requiring not to 

Re: [FFmpeg-devel] [PATCH 1/2 v2] avfilter: add readvitc filter

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> > Instead of listing the formats, check for pix_fmts
> > that are 8bit and planar.
> 
> Nope, bad idea.

Please elaborate: Why would yuva420p not be an allowed 
input format?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: honor iOS calling convention

[Clément Bœsch]

From: Clément Bœsch 

y_offset and y_coeff being successive 32-bit integers, they are packed
into 8 bytes instead of 2x8 bytes.

See 
https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html

> iOS diverges from Procedure Call Standard for the ARM 64-bit
> Architecture in several ways
[...]
> In the generic procedure call standard, all function arguments passed
> on the stack consume slots in multiples of 8 bytes. In iOS, this
> requirement is dropped, and values consume only the space required.
[...]
> Padding is still inserted on the stack to satisfy arguments’ alignment
> requirements.
---
 libswscale/aarch64/yuv2rgb_neon.S | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/libswscale/aarch64/yuv2rgb_neon.S 
b/libswscale/aarch64/yuv2rgb_neon.S
index 8cefe22..b7446aa 100644
--- a/libswscale/aarch64/yuv2rgb_neon.S
+++ b/libswscale/aarch64/yuv2rgb_neon.S
@@ -21,10 +21,18 @@
 
 #include "libavutil/aarch64/asm.S"
 
+.macro load_yoff_ycoeff yoff ycoeff
+#if defined(__APPLE__)
+ldp w9, w10, [sp, #\yoff]
+#else
+ldr w9,  [sp, #\yoff]
+ldr w10, [sp, #\ycoeff]
+#endif
+.endm
+
 .macro load_args_nv12
 ldr x8,  [sp]   // 
table
-ldr w9,  [sp, #8]   // 
y_offset
-ldr w10, [sp, #16]  // 
y_coeff
+load_yoff_ycoeff8, 16   // 
y_offset, y_coeff
 ld1 {v1.1D}, [x8]
 dup v0.8H, w10
 dup v3.8H, w9
@@ -42,8 +50,7 @@
 ldr x13, [sp]   // srcV
 ldr w14, [sp, #8]   // 
linesizeV
 ldr x8,  [sp, #16]  // 
table
-ldr w9,  [sp, #24]  // 
y_offset
-ldr w10, [sp, #32]  // 
y_coeff
+load_yoff_ycoeff24, 32  // 
y_offset, y_coeff
 ld1 {v1.1D}, [x8]
 dup v0.8H, w10
 dup v3.8H, w9
@@ -59,8 +66,7 @@
 ldr x13, [sp]   // srcV
 ldr w14, [sp, #8]   // 
linesizeV
 ldr x8,  [sp, #16]  // 
table
-ldr w9,  [sp, #24]  // 
y_offset
-ldr w10, [sp, #32]  // 
y_coeff
+load_yoff_ycoeff24, 32  // 
y_offset, y_coeff
 ld1 {v1.1D}, [x8]
 dup v0.8H, w10
 dup v3.8H, w9
-- 
2.8.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] hardware codec for ffmpeg upstream

[Moritz Barsnick]

On Fri, Apr 08, 2016 at 14:30:13 +0800, Jung Zhao wrote:
> Yes, I have written. Any code format and patch rules I need to abide?

Yes, plenty.
See http://ffmpeg.org/developer.html (all of it), and for the patches
particularily http://ffmpeg.org/developer.html#Submitting-patches .

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v2] avfilter: add readvitc filter

[Paul B Mahol]

On 4/8/16, Carl Eugen Hoyos  wrote:
> Paul B Mahol  gmail.com> writes:
>
>> > Instead of listing the formats, check for pix_fmts
>> > that are 8bit and planar.
>>
>> Nope, bad idea.
>
> Please elaborate: Why would yuva420p not be an allowed
> input format?

Because it is not used. It can be added to the _static_ list.

>
> Carl Eugen
>
> ___
> 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 1/2 v3] avfilter: add readvitc filter

[Tobias Rapp]

On 08.04.2016 12:48, Carl Eugen Hoyos wrote:

Tobias Rapp  noa-archive.com> writes:


AV_PIX_FMT_YUV440P? Also J variants...


Good catch, I was lazy and just copied the function from vf_eq.c. The
updated patch should contain all pixel formats with planar 8bit luma
component.


Instead of listing the formats, check for pix_fmts
that are 8bit and planar.


That might be an even better idea. Working on v3 of the patch I noticed 
that YA8 (which was on the list of v2) is not planar, but NV12 and NV21 
(which were missing in v2) have a planar Y.


Have attached version 3 of the patch which:
- filters the list of all pixel formats dynamically
- supports thr_b and thr_w parameters having the same value
- updates the warning if thr_b == thr_w to print the parameter value 
instead of the internal 8-bit value

- has reduced number of parentheses in CRC code

Regards,
Tobias
>From 8f42ba13e68ff462b2bccd2de4906fe5b782ab96 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Wed, 6 Apr 2016 16:25:53 +0200
Subject: [PATCH 1/2] avfilter: add readvitc filter

Add a filter to scan the top lines of video frames for vertical interval
timecode (VITC) information and attach it as metadata keys.

Signed-off-by: Tobias Rapp 
---
 Changelog |   1 +
 MAINTAINERS   |   1 +
 doc/filters.texi  |  26 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/version.h |   4 +-
 libavfilter/vf_readvitc.c | 253 ++
 7 files changed, 285 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_readvitc.c

diff --git a/Changelog b/Changelog
index b4a4dd7..51613d6 100644
--- a/Changelog
+++ b/Changelog
@@ -22,6 +22,7 @@ version :
 - musx demuxer
 - aix demuxer
 - remap filter
+- readvitc filter
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..d2593e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -385,6 +385,7 @@ Filters:
   vf_neighbor.c Paul B Mahol
   vf_psnr.c Paul B Mahol
   vf_random.c   Paul B Mahol
+  vf_readvitc.c Tobias Rapp (CC t.rapp at noa-archive dot com)
   vf_scale.cMichael Niedermayer
   vf_separatefields.c   Paul B Mahol
   vf_ssim.c Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index e848584..1004294 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10430,6 +10430,32 @@ less than @code{0}, the filter will try to use a good random seed on a
 best effort basis.
 @end table
 
+@section readvitc
+
+Read vertical interval timecode (VITC) information from the top lines of a
+video frame.
+
+The filter adds frame metadata key @code{lavfi.readvitc.tc_str} with the
+timecode value, if a valid timecode has been detected. Further metadata key
+@code{lavfi.readvitc.found} is set to 0/1 depending on whether
+timecode data has been found or not.
+
+This filter accepts the following options:
+
+@table @option
+@item scan_max
+Set the maximum number of lines to scan for VITC data. If the value is set to
+@code{-1} the full video frame is scanned. Default is @code{45}.
+
+@item thr_b
+Set the luma threshold for black. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.2}. The value must be equal or less than @code{thr_w}.
+
+@item thr_w
+Set the luma threshold for white. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.6}. The value must be equal or greater than @code{thr_b}.
+@end table
+
 @section remap
 
 Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3a3de48..0994d46 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -223,6 +223,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o dualinput.o framesync.
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
 OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
 OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG_REALTIME_FILTER)   += f_realtime.o
 OBJS-$(CONFIG_REMAP_FILTER)  += vf_remap.o framesync.o
 OBJS-$(CONFIG_REMOVEGRAIN_FILTER)+= vf_removegrain.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b6f4a2c..d59b2d8 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -243,6 +243,7 @@ void avfilter_register_all(void)
 REGISTER_FILTER(PULLUP, pullup, vf);
 REGISTER_FILTER(QP, qp, vf);
 REGISTER_FILTER(RANDOM, random, vf);
+REGISTER_FILTER(READVITC,   readvitc,   vf);
 REGISTER_FILTER(REALTIME,   realtime,   vf);
 REGISTER_FILTER(REMAP,  remap,  vf);
 REGISTER_FIL

Re: [FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[Paul B Mahol]

On 4/8/16, Tobias Rapp  wrote:
> On 08.04.2016 12:48, Carl Eugen Hoyos wrote:
>> Tobias Rapp  noa-archive.com> writes:
>>
 AV_PIX_FMT_YUV440P? Also J variants...
>>>
>>> Good catch, I was lazy and just copied the function from vf_eq.c. The
>>> updated patch should contain all pixel formats with planar 8bit luma
>>> component.
>>
>> Instead of listing the formats, check for pix_fmts
>> that are 8bit and planar.
>
> That might be an even better idea. Working on v3 of the patch I noticed
> that YA8 (which was on the list of v2) is not planar, but NV12 and NV21
> (which were missing in v2) have a planar Y.
>
> Have attached version 3 of the patch which:
> - filters the list of all pixel formats dynamically
> - supports thr_b and thr_w parameters having the same value
> - updates the warning if thr_b == thr_w to print the parameter value
> instead of the internal 8-bit value
> - has reduced number of parentheses in CRC code
>
> Regards,
> Tobias
>

Now, when someone adds 8bit X planar format which is not YUV it will break.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for datawindow who exceed display window

[Martin Vignali]

I answer here to Carl, because his comments are about the display
window/data window patch.

2016-04-08 13:00 GMT+02:00 Carl Eugen Hoyos :

> Martin Vignali  gmail.com> writes:
>
> > -line = AV_RL32(src - 8);
> > +line = (int32_t)AV_RL32(src - 8);
>
> This change is ugly and should be unneeded.
>

Before this patch datawindow/displaywindow, are interpret as positive value.
For a correct management of display window/datawindow, we need to use
int32_t.

Without this line modification, i have had some trouble (compiler clang, OS
10.9), where "line" doesn't always get a negative value as it should be.
What do you recommand instead ?


>
> > +channel_buffer[0] += channelLineSize * line_to_skip;
> > +channel_buffer[1] += channelLineSize * line_to_skip;
> > +channel_buffer[2] += channelLineSize * line_to_skip;
> > +if (channel_buffer[3])
> > +channel_buffer[3] += channelLineSize * line_to_skip;
>
> > +channel_buffer[0] += channelLineSize;
> > +channel_buffer[1] += channelLineSize;
> > +channel_buffer[2] += channelLineSize;
> > +if (channel_buffer[3])
> > +channel_buffer[3] += channelLineSize;
>
> for() loops?
>

I mostly follow here, the same way that already is in the EXR Decoder.
But i can make a loop.

The other solution, is to let for now, these lines.
And i will change it in a future patch (for Luma, Luma/Alpha support, where
i will need to change theses parts)


>
> > +if (s->pixel_type == EXR_HALF)
> > +s->pixel_size = 2;
> > +else
> > +s->pixel_size = 4;
> > +
>
> Please add braces.
>

Ok, i can add, it, i thought, in ffmpeg, you prefer to doesn't add brace, i
there is only one line after if.

Thanks for the comment

Martin
Jokyo Images
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[Tobias Rapp]

On 08.04.2016 14:54, Paul B Mahol wrote:

On 4/8/16, Tobias Rapp  wrote:

On 08.04.2016 12:48, Carl Eugen Hoyos wrote:

Tobias Rapp  noa-archive.com> writes:


AV_PIX_FMT_YUV440P? Also J variants...


Good catch, I was lazy and just copied the function from vf_eq.c. The
updated patch should contain all pixel formats with planar 8bit luma
component.


Instead of listing the formats, check for pix_fmts
that are 8bit and planar.


That might be an even better idea. Working on v3 of the patch I noticed
that YA8 (which was on the list of v2) is not planar, but NV12 and NV21
(which were missing in v2) have a planar Y.

Have attached version 3 of the patch which:
- filters the list of all pixel formats dynamically
- supports thr_b and thr_w parameters having the same value
- updates the warning if thr_b == thr_w to print the parameter value
instead of the internal 8-bit value
- has reduced number of parentheses in CRC code

Regards,
Tobias



Now, when someone adds 8bit X planar format which is not YUV it will break.


It depends on whether the equation "is_yuv_or_gray = (desc->flags & 
AV_PIX_FMT_FLAG_RGB) == 0)" can be made or not. The comment in 
libavutil/pixdesc.h made me assume it is safe to do so:


"""
/**
 * The pixel format contains RGB-like data (as opposed to YUV/grayscale).
 */
#define AV_PIX_FMT_FLAG_RGB  (1 << 5)
"""

So what has more weight, the aspect of defensive programming or the cost 
of maintaining a static list?


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] ffservers future

[Michael Niedermayer]

Hi all

If people want ffserver to continue to exist in a functional form then
ffserver needs a new maintainer or developers taking care of it /
giving it some love.
There are a few known bugs in it like code depending on
sizeof(AVStream) and general a little too much direct access into APIs
these things will cause ffserver to frequently break if APIs change
even slightly.
I dont think this is a major amount of work, at least not as long as
one doesnt get onto the path of rewriting things to be "clean" in a
philosophical sense but just "clean" in a working and maintainable
sense.

If noone picks up ffserver and "helps it into the year 2016" then
eventually ffserver will just stop working when its way of using the
APIs drifted too much from the changing reality. And once it totally
doesnt work anymore, fixing it could be harder ...

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[Carl Eugen Hoyos]

Tobias Rapp  noa-archive.com> writes:

> > Now, when someone adds 8bit X planar format which is not 
> > YUV it will break.
> 
> It depends on whether the equation 
> "is_yuv_or_gray = (desc->flags & AV_PIX_FMT_FLAG_RGB) == 0)" 
> can be made or not.

Wouldn't the algorithm also work for GBR?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for datawindow who exceed display window

[Carl Eugen Hoyos]

Martin Vignali  gmail.com> writes:

> I answer here to Carl, because his comments are about 
> the display window/data window patch.

Sorry about it, I know it's annoying...

> > > -line = AV_RL32(src - 8);
> > > +line = (int32_t)AV_RL32(src - 8);
> >
> > This change is ugly and should be unneeded.

If my comment was wrong please ignore;-)

[...]

> > > +if (s->pixel_type == EXR_HALF)
> > > +s->pixel_size = 2;
> > > +else
> > > +s->pixel_size = 4;
> > > +
> >
> > Please add braces.
> >
> 
> Ok, i can add, it, i thought, in ffmpeg, you prefer to 
> doesn't add brace

The reason if - else should always have braces is that 
this makes future changes much easier to read and 
costs only one line.

Thank you, Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/2] add readvitc filter

[Clément Bœsch]

On Fri, Apr 08, 2016 at 10:50:23AM +0200, Tobias Rapp wrote:
> The following patches add a filter that allows to scan video frames for VITC
> lines, including FATE test.
> 
> The sample file for the FATE test can be found at:
> https://cerebrum.noa-archive.com/noacloud/public.php?service=files&t=88eeb716819bba39584be03c2d1f053b
>  (1.4MB)
> and is assumed to be stored as $FATE_SAMPLES/filter/sample-vitc.avi
> 
> MD5SUM:150ca9d1f6283f136ce14bd7a7cf025e
> SHA256SUM: ec39eeda7587536a4c90ae14288e895defa8fc64c536eeca88b34899a963d42f
> 

Hey that's pretty cool. I'll check that patch later.

BTW, how about updating drawtext filter so it can pick the timecode
information from metadata? We already have drawtext code handling
timecode printing.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[Tobias Rapp]

On 08.04.2016 15:38, Carl Eugen Hoyos wrote:

Tobias Rapp  noa-archive.com> writes:


Now, when someone adds 8bit X planar format which is not
YUV it will break.


It depends on whether the equation
"is_yuv_or_gray = (desc->flags & AV_PIX_FMT_FLAG_RGB) == 0)"
can be made or not.


Wouldn't the algorithm also work for GBR?


If VITC lines are green, yes :-). In general the filter requires a 
luma/gray/Y component in plane 0.


Regards,
Tobias

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/2] add readvitc filter

[Tobias Rapp]

On 08.04.2016 15:49, Clément Bœsch wrote:

On Fri, Apr 08, 2016 at 10:50:23AM +0200, Tobias Rapp wrote:

The following patches add a filter that allows to scan video frames for VITC
lines, including FATE test.

The sample file for the FATE test can be found at:
https://cerebrum.noa-archive.com/noacloud/public.php?service=files&t=88eeb716819bba39584be03c2d1f053b
 (1.4MB)
and is assumed to be stored as $FATE_SAMPLES/filter/sample-vitc.avi

MD5SUM:150ca9d1f6283f136ce14bd7a7cf025e
SHA256SUM: ec39eeda7587536a4c90ae14288e895defa8fc64c536eeca88b34899a963d42f



Hey that's pretty cool. I'll check that patch later.

BTW, how about updating drawtext filter so it can pick the timecode
information from metadata? We already have drawtext code handling
timecode printing.


This should already be possible using a filter string like

'drawtext=fontfile=...:text=%{metadata\\:lavfi.readvitc.tc_str}'

and with the patch from [1] you can even do

'drawtext=fontfile=...:text=%{metadata\\:lavfi.readvitc.tc_str\\:--\\:--\\:--\\:--}'

Regards,
Tobias

Link:
[1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-April/192779.html

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: honor iOS calling convention

[Ronald S. Bultje]

Hi,

On Fri, Apr 8, 2016 at 7:41 AM, Clément Bœsch  wrote:

> From: Clément Bœsch 
>
> y_offset and y_coeff being successive 32-bit integers, they are packed
> into 8 bytes instead of 2x8 bytes.


lgtm.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2 v4] avfilter: add readvitc filter

[Tobias Rapp]

On 08.04.2016 15:24, Tobias Rapp wrote:

On 08.04.2016 14:54, Paul B Mahol wrote:

On 4/8/16, Tobias Rapp  wrote:

On 08.04.2016 12:48, Carl Eugen Hoyos wrote:

Tobias Rapp  noa-archive.com> writes:


AV_PIX_FMT_YUV440P? Also J variants...


Good catch, I was lazy and just copied the function from vf_eq.c. The
updated patch should contain all pixel formats with planar 8bit luma
component.


Instead of listing the formats, check for pix_fmts
that are 8bit and planar.


That might be an even better idea. Working on v3 of the patch I noticed
that YA8 (which was on the list of v2) is not planar, but NV12 and NV21
(which were missing in v2) have a planar Y.

Have attached version 3 of the patch which:
- filters the list of all pixel formats dynamically
- supports thr_b and thr_w parameters having the same value
- updates the warning if thr_b == thr_w to print the parameter value
instead of the internal 8-bit value
- has reduced number of parentheses in CRC code

Regards,
Tobias



Now, when someone adds 8bit X planar format which is not YUV it will
break.


It depends on whether the equation "is_yuv_or_gray = (desc->flags &
AV_PIX_FMT_FLAG_RGB) == 0)" can be made or not. The comment in
libavutil/pixdesc.h made me assume it is safe to do so:

"""
/**
  * The pixel format contains RGB-like data (as opposed to YUV/grayscale).
  */
#define AV_PIX_FMT_FLAG_RGB  (1 << 5)
"""

So what has more weight, the aspect of defensive programming or the cost
of maintaining a static list?


Attached patch v4 contains the more defensive static-pixfmt-list 
approach together with the threshold changes from v3.


Regards,
Tobias
>From db7fd9bbf63c0404f40fd45248047571f4fc8dfc Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Wed, 6 Apr 2016 16:25:53 +0200
Subject: [PATCH 1/2] avfilter: add readvitc filter

Add a filter to scan the top lines of video frames for vertical interval
timecode (VITC) information and attach it as metadata keys.

Signed-off-by: Tobias Rapp 
---
 Changelog |   1 +
 MAINTAINERS   |   1 +
 doc/filters.texi  |  26 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/version.h |   4 +-
 libavfilter/vf_readvitc.c | 258 ++
 7 files changed, 290 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vf_readvitc.c

diff --git a/Changelog b/Changelog
index b4a4dd7..51613d6 100644
--- a/Changelog
+++ b/Changelog
@@ -22,6 +22,7 @@ version :
 - musx demuxer
 - aix demuxer
 - remap filter
+- readvitc filter
 
 version 3.0:
 - Common Encryption (CENC) MP4 encoding and decoding support
diff --git a/MAINTAINERS b/MAINTAINERS
index a993a67..d2593e5 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -385,6 +385,7 @@ Filters:
   vf_neighbor.c Paul B Mahol
   vf_psnr.c Paul B Mahol
   vf_random.c   Paul B Mahol
+  vf_readvitc.c Tobias Rapp (CC t.rapp at noa-archive dot com)
   vf_scale.cMichael Niedermayer
   vf_separatefields.c   Paul B Mahol
   vf_ssim.c Paul B Mahol
diff --git a/doc/filters.texi b/doc/filters.texi
index e848584..1004294 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10430,6 +10430,32 @@ less than @code{0}, the filter will try to use a good random seed on a
 best effort basis.
 @end table
 
+@section readvitc
+
+Read vertical interval timecode (VITC) information from the top lines of a
+video frame.
+
+The filter adds frame metadata key @code{lavfi.readvitc.tc_str} with the
+timecode value, if a valid timecode has been detected. Further metadata key
+@code{lavfi.readvitc.found} is set to 0/1 depending on whether
+timecode data has been found or not.
+
+This filter accepts the following options:
+
+@table @option
+@item scan_max
+Set the maximum number of lines to scan for VITC data. If the value is set to
+@code{-1} the full video frame is scanned. Default is @code{45}.
+
+@item thr_b
+Set the luma threshold for black. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.2}. The value must be equal or less than @code{thr_w}.
+
+@item thr_w
+Set the luma threshold for white. Accepts float numbers in the range [0.0,1.0],
+default value is @code{0.6}. The value must be equal or greater than @code{thr_b}.
+@end table
+
 @section remap
 
 Remap pixels using 2nd: Xmap and 3rd: Ymap input video stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3a3de48..0994d46 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -223,6 +223,7 @@ OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o dualinput.o framesync.
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
 OBJS-$(CONFIG_QP_FILTER) += vf_qp.o
 OBJS-$(CONFIG_RANDOM_FILTER) += vf_random.o
+OBJS-$(CONFIG_READVITC_FILTER)   += vf_readvitc.o
 OBJS-$(CONFIG

Re: [FFmpeg-devel] [PATCH 1/2 v3] avfilter: add readvitc filter

[wm4]

On Fri, 8 Apr 2016 15:24:56 +0200
Tobias Rapp  wrote:

> On 08.04.2016 14:54, Paul B Mahol wrote:
> > On 4/8/16, Tobias Rapp  wrote:  
> >> On 08.04.2016 12:48, Carl Eugen Hoyos wrote:  
> >>> Tobias Rapp  noa-archive.com> writes:
> >>>  
> > AV_PIX_FMT_YUV440P? Also J variants...  
> 
>  Good catch, I was lazy and just copied the function from vf_eq.c. The
>  updated patch should contain all pixel formats with planar 8bit luma
>  component.  
> >>>
> >>> Instead of listing the formats, check for pix_fmts
> >>> that are 8bit and planar.  
> >>
> >> That might be an even better idea. Working on v3 of the patch I noticed
> >> that YA8 (which was on the list of v2) is not planar, but NV12 and NV21
> >> (which were missing in v2) have a planar Y.
> >>
> >> Have attached version 3 of the patch which:
> >> - filters the list of all pixel formats dynamically
> >> - supports thr_b and thr_w parameters having the same value
> >> - updates the warning if thr_b == thr_w to print the parameter value
> >> instead of the internal 8-bit value
> >> - has reduced number of parentheses in CRC code
> >>
> >> Regards,
> >> Tobias
> >>  
> >
> > Now, when someone adds 8bit X planar format which is not YUV it will break. 
> >  
> 
> It depends on whether the equation "is_yuv_or_gray = (desc->flags & 
> AV_PIX_FMT_FLAG_RGB) == 0)" can be made or not. The comment in 
> libavutil/pixdesc.h made me assume it is safe to do so:
> 
> """
> /**
>   * The pixel format contains RGB-like data (as opposed to YUV/grayscale).
>   */
> #define AV_PIX_FMT_FLAG_RGB  (1 << 5)
> """
> 
> So what has more weight, the aspect of defensive programming or the cost 
> of maintaining a static list?

There are more colorspaces than RGB and YUV.

I'd say either hardcode the list, or introduce libavutil utility
functions which can "classify" a pixfmt in certain ways useful to such
filters.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Will Kelleher]

Signed-off-by: Will Kelleher 
---
 libavcodec/hevc_parser.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 4625e61..5558afc 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -202,6 +202,9 @@ static inline int parse_nal_units(AVCodecParserContext *s, 
const uint8_t *buf,
 
 gb = &h->HEVClc->gb;
 
+h->a53_caption_size = 0;
+av_freep(&h->a53_caption);
+
 /* set some sane default values */
 s->pict_type = AV_PICTURE_TYPE_I;
 s->key_frame = 0;
-- 
2.8.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] sws/aarch64: add ff_yuv2planeX_8_neon

[Clément Bœsch]

From: Clément Bœsch 

---
 libswscale/aarch64/Makefile  |  1 +
 libswscale/aarch64/output.S  | 66 
 libswscale/aarch64/swscale.c |  7 +
 libswscale/utils.c   |  3 +-
 4 files changed, 76 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/aarch64/output.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index 51bff08..64a3fe2 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -2,4 +2,5 @@ OBJS+= aarch64/swscale.o\
aarch64/swscale_unscaled.o   \
 
 NEON-OBJS   += aarch64/hscale.o \
+   aarch64/output.o \
aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/output.S b/libswscale/aarch64/output.S
new file mode 100644
index 000..31809b4
--- /dev/null
+++ b/libswscale/aarch64/output.S
@@ -0,0 +1,66 @@
+/*
+ * Copyright (c) 2016 Clément Bœsch 
+ *
+ * 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"
+
+function ff_yuv2planeX_8_neon, export=1
+ld1 {v0.8B}, [x5]   // load 8x8-bit 
dither
+cbz w6, 1f  // check if 
offseting present
+ext v0.8B, v0.8B, v0.8B, #3 // honor offseting 
which can be 0 or 3 only
+1:  uxtlv0.8H, v0.8B// extend dither 
to 16-bit
+ushll   v1.4S, v0.4H, #12   // extend dither 
to 32-bit with left shift by 12 (part 1)
+ushll2  v2.4S, v0.8H, #12   // extend dither 
to 32-bit with left shift by 12 (part 2)
+mov x7, #0  // i = 0
+2:  mov v3.16B, v1.16B  // initialize 
accumulator part 1 with dithering value
+mov v4.16B, v2.16B  // initialize 
accumulator part 2 with dithering value
+mov w8, w1  // tmpfilterSize = 
filterSize
+mov x9, x2  // srcp= src
+mov x10, x0 // filterp = filter
+3:  ldp x11, x12, [x9], #16 // get 2 pointers: 
src[j] and src[j+1]
+add x11, x11, x7, lsl #1// &src[j  ][i]
+add x12, x12, x7, lsl #1// &src[j+1][i]
+ld1 {v5.8H}, [x11]  // read 8x16-bit @ 
src[j  ][i + {0..7}]: A,B,C,D,E,F,G,H
+ld1 {v6.8H}, [x12]  // read 8x16-bit @ 
src[j+1][i + {0..7}]: I,J,K,L,M,N,O,P
+ldr w11, [x10], #4  // read 2x16-bit 
coeffs (X, Y) at (filter[j], filter[j+1])
+zip1v16.8H, v5.8H, v6.8H// A,I,B,J,C,K,D,L
+zip2v17.8H, v5.8H, v6.8H// E,M,F,N,F,O,H,P
+dup v7.4S, w11  // X,Y,X,Y,X,Y,X,Y
+smull   v18.4S, v16.4H, v7.4H   // A.X I.Y B.X J.Y
+smull   v20.4S, v17.4H, v7.4H   // E.X M.Y F.X N.Y
+smull2  v19.4S, v16.8H, v7.8H   // C.X K.Y D.X L.Y
+smull2  v21.4S, v17.8H, v7.8H   // G.X O.Y H.X P.Y
+addpv16.4S, v18.4S, v19.4S  // A.X+I.Y B.X+J.Y 
C.X+K.Y D.X+L.Y
+addpv17.4S, v20.4S, v21.4S  // E.X+M.Y F.X+N.Y 
F.X+O.Y H.X+P.Y
+add v3.4S, v3.4S, v16.4S// update val 
accumulator for part 1
+add v4.4S, v4.4S, v17.4S// update val 
accumulator for part 2
+subsw8, w8, #2  // tmpfilterSize 
-= 2
+b.gt3b  // loop until 
filterSize consumed
+sshrv3.4S, v3.4S, #19   // val>>19 (part 1)
+sshrv4.4S, v4.4S, #19   // val>>19 (part 2)
+sqxtun  v3.4H, v3.4S// clip16(val>>19) 

Re: [FFmpeg-devel] [PATCH] sws/aarch64: add ff_yuv2planeX_8_neon

[Clément Bœsch]

On Fri, Apr 08, 2016 at 05:35:20PM +0200, Clément Bœsch wrote:
> From: Clément Bœsch 
> 
> ---
>  libswscale/aarch64/Makefile  |  1 +
>  libswscale/aarch64/output.S  | 66 
> 
>  libswscale/aarch64/swscale.c |  7 +
>  libswscale/utils.c   |  3 +-
>  4 files changed, 76 insertions(+), 1 deletion(-)
>  create mode 100644 libswscale/aarch64/output.S
> 

./ffmpeg -nostats -f lavfi -i 
testsrc2=uhd4320:d=1,format=yuv420p,bench=start,scale=1024x1024,bench=stop -f 
null -

before: [bench @ 0x37706390] t:0.395010 avg:0.395212 max:0.397024 min:0.394710
after:  [bench @ 0x22101390] t:0.262277 avg:0.262560 max:0.264740 min:0.260876

[...]

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] sws/aarch64/yuv2rgb: honor iOS calling convention

[Clément Bœsch]

On Fri, Apr 08, 2016 at 10:25:13AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Fri, Apr 8, 2016 at 7:41 AM, Clément Bœsch  wrote:
> 
> > From: Clément Bœsch 
> >
> > y_offset and y_coeff being successive 32-bit integers, they are packed
> > into 8 bytes instead of 2x8 bytes.
> 
> 
> lgtm.
> 

applied, thanks

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffservers future

[Derek Buitenhuis]

On 4/8/2016 2:30 PM, Michael Niedermayer wrote:
> There are a few known bugs in it like code depending on
> sizeof(AVStream) and general a little too much direct access into APIs
> these things will cause ffserver to frequently break if APIs change
> even slightly.

To calrify, the problem is accessing and allocating *internal* structures.

As in, it includes libavformat/internal.h.

So any change in *non-public* API there breaks it.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] ffservers future

[wm4]

On Fri, 8 Apr 2016 18:13:53 +0100
Derek Buitenhuis  wrote:

> On 4/8/2016 2:30 PM, Michael Niedermayer wrote:
> > There are a few known bugs in it like code depending on
> > sizeof(AVStream) and general a little too much direct access into APIs
> > these things will cause ffserver to frequently break if APIs change
> > even slightly.  
> 
> To calrify, the problem is accessing and allocating *internal* structures.
> 
> As in, it includes libavformat/internal.h.
> 
> So any change in *non-public* API there breaks it.

Well, it also has significant code in libavformat, and assume a lot
about other internals. With a design like this it's a given how fragile
it is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 8/8] lavf/movenc+dashenc: add automatic bitstream filtering

[Derek Buitenhuis]

On 4/8/2016 1:38 AM, Rodger Combs wrote:
> @@ -617,6 +617,7 @@ static int dash_write_header(AVFormatContext *s)
>  ctx->opaque = s->opaque;
>  ctx->io_close   = s->io_close;
>  ctx->io_open= s->io_open;
> +av_dict_set(&opts, "fflags", "-autobsf", 0);

Don't do this. This is a SILENT API break. You should have to explicitly
enable it, not add a line to disable it to keep current code working.
This will screw any API user who uses the DASH muxing API.

- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 10:05:13AM -0500, Will Kelleher wrote:
> Signed-off-by: Will Kelleher 
> ---
>  libavcodec/hevc_parser.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index 4625e61..5558afc 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -202,6 +202,9 @@ static inline int parse_nal_units(AVCodecParserContext 
> *s, const uint8_t *buf,
>  
>  gb = &h->HEVClc->gb;
>  
> +h->a53_caption_size = 0;
> +av_freep(&h->a53_caption);
> +

shouldnt this be in hevc_parser_close() ?

(actually it probably belongs somewhere closer into hevc as the code
 allocating should also free but the other allocs are also seperate
 from the freeing ...)

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397

[Michael Niedermayer]

On Wed, Apr 06, 2016 at 12:25:48AM +0200, Clément Bœsch wrote:
> On Sat, Apr 02, 2016 at 03:49:12AM +0200, Michael Niedermayer wrote:
> > If someone can create a smaller test file (its 2.5Mb) that still has the 
> > same coverage that is welcome.
> > otherwise ill upload the sample attached to the ticket
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tests/fate/filter-video.mak|4 +
> >  tests/filtergraphs/overlay-2397|2 +
> >  tests/ref/fate/filter-overlay-2397 |  848 
> > 
> >  3 files changed, 854 insertions(+)
> >  create mode 100644 tests/filtergraphs/overlay-2397
> >  create mode 100644 tests/ref/fate/filter-overlay-2397
> > 
> > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> > index 7fb7677..5fd6ae0 100644
> > --- a/tests/fate/filter-video.mak
> > +++ b/tests/fate/filter-video.mak
> > @@ -304,6 +304,10 @@ FATE_FILTER-$(call ALLYES, SMJPEG_DEMUXER 
> > MJPEG_DECODER PERMS_FILTER HQDN3D_FILT
> >  fate-filter-hqdn3d-sample: tests/data/filtergraphs/hqdn3d
> >  fate-filter-hqdn3d-sample: CMD = framecrc -idct simple -i 
> > $(TARGET_SAMPLES)/smjpeg/scenwin.mjpg -filter_complex_script 
> > $(TARGET_PATH)/tests/data/filtergraphs/hqdn3d -an
> >  
> > +FATE_FILTER-$(call ALLYES, MATROSKA_DEMUXER OVERLAY_FILTER H264_DECODER 
> > DVDSUB_DECODER) += fate-filter-overlay-2397
> > +fate-filter-overlay-2397: tests/data/filtergraphs/overlay-2397
> > +fate-filter-overlay-2397: CMD = framecrc -flags bitexact -i 
> > $(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
> > $(TARGET_PATH)/tests/data/filtergraphs/overlay-2397 -c:a copy
> > +
> 
> is it relevant to include the audio?

hmm, the user would likely use audio, so including audio is more
realistic/closer to what a user would do


> 
> also i'd better mention "dvdsub" than the ticket id (commit message should
> still contain the reference to the ticket though).

changed

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Will Kelleher]

On 04/08, Michael Niedermayer wrote:
> On Fri, Apr 08, 2016 at 10:05:13AM -0500, Will Kelleher wrote:
> > Signed-off-by: Will Kelleher 
> > ---
> >  libavcodec/hevc_parser.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > index 4625e61..5558afc 100644
> > --- a/libavcodec/hevc_parser.c
> > +++ b/libavcodec/hevc_parser.c
> > @@ -202,6 +202,9 @@ static inline int parse_nal_units(AVCodecParserContext 
> > *s, const uint8_t *buf,
> >  
> >  gb = &h->HEVClc->gb;
> >  
> > +h->a53_caption_size = 0;
> > +av_freep(&h->a53_caption);
> > +
> 
> shouldnt this be in hevc_parser_close() ?
> 
> (actually it probably belongs somewhere closer into hevc as the code
>  allocating should also free but the other allocs are also seperate
>  from the freeing ...)

Let me spend a little more time tracing the hevc decode process - I
probably don't understand this code as well as I should.  I have just been
mirroring the existing h264 implementation of this feature.

The a53_caption buffer is normally realloc'd when each sei_nal is
parsed, and then freed after it gets written to the output frame's
side data in hevc_frame_start.

> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Opposition brings concord. Out of discord comes the fairest harmony.
> -- Heraclitus



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fffmpeg.org%2fmailman%2flistinfo%2fffmpeg-devel&data=01%7c01%7cwkelleher%40gogoair.com%7c7aa319b8e9d24407b0f708d35fdc8f3a%7c2e6508518649457ea18abc0264c3b7d0%7c1&sdata=G%2fCXmmQ3nQspFp%2bYaAEtgR5sPoLSfb2IMhJML7wOZWc%3d

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397

[wm4]

On Sat,  2 Apr 2016 03:49:12 +0200
Michael Niedermayer  wrote:

> If someone can create a smaller test file (its 2.5Mb) that still has the same 
> coverage that is welcome.
> otherwise ill upload the sample attached to the ticket

The commit message should describe exactly what the test is about and
why it's needed. The issue tracker might be long gone when someone hits
this when running "git blame", besides it's annoying to look up the
issue and to understand it. (You'd have to read the entire issue, which
in general will be full of confusion until the real cause is found.
Understanding it from scratch is a lot different from when you already
know what's it about.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 02:35:09PM -0500, Will Kelleher wrote:
> On 04/08, Michael Niedermayer wrote:
> > On Fri, Apr 08, 2016 at 10:05:13AM -0500, Will Kelleher wrote:
> > > Signed-off-by: Will Kelleher 
> > > ---
> > >  libavcodec/hevc_parser.c | 3 +++
> > >  1 file changed, 3 insertions(+)
> > > 
> > > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > > index 4625e61..5558afc 100644
> > > --- a/libavcodec/hevc_parser.c
> > > +++ b/libavcodec/hevc_parser.c
> > > @@ -202,6 +202,9 @@ static inline int 
> > > parse_nal_units(AVCodecParserContext *s, const uint8_t *buf,
> > >  
> > >  gb = &h->HEVClc->gb;
> > >  
> > > +h->a53_caption_size = 0;
> > > +av_freep(&h->a53_caption);
> > > +
> > 
> > shouldnt this be in hevc_parser_close() ?
> > 
> > (actually it probably belongs somewhere closer into hevc as the code
> >  allocating should also free but the other allocs are also seperate
> >  from the freeing ...)
> 
> Let me spend a little more time tracing the hevc decode process - I
> probably don't understand this code as well as I should.  I have just been
> mirroring the existing h264 implementation of this feature.
> 

> The a53_caption buffer is normally realloc'd when each sei_nal is
> parsed, and then freed after it gets written to the output frame's
> side data in hevc_frame_start.

and if an error happens between it leaks ?


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: Add test for Ticket 2397

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 09:49:34PM +0200, wm4 wrote:
> On Sat,  2 Apr 2016 03:49:12 +0200
> Michael Niedermayer  wrote:
> 
> > If someone can create a smaller test file (its 2.5Mb) that still has the 
> > same coverage that is welcome.
> > otherwise ill upload the sample attached to the ticket
> 
> The commit message should describe exactly what the test is about and
> why it's needed. The issue tracker might be long gone when someone hits
> this when running "git blame", besides it's annoying to look up the
> issue and to understand it. (You'd have to read the entire issue, which
> in general will be full of confusion until the real cause is found.
> Understanding it from scratch is a lot different from when you already
> know what's it about.)

agree, but i already pushed this :(

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for datawindow who exceed display window

[Paul B Mahol]

On 4/7/16, Martin Vignali  wrote:
> Hello,
>
> in attach, a patch with some modifications in size/data window management,
> in order to manage
> negative datawindow/display window, and datawindow who can exceed display
> window
>
> Size of the picture is now set from min and max value of the display window
> (before the patch, xmin, ymin of the display window are ignored (and assume
> to be 0))
>
> With the previous patch (fix channel detection), official samples
> ./scanline/Blobbies.exr
> can now be correctly decode.
>
>
> DataWindow bigger than display window is a feature of the openExr.
> It can be use in some softwares, (for example to improve blur quality)
> Following the official documentation, for display, we need to use the
> display window only.
>
>
> In this patch, xmin, xmax, ymin, ymax, are now int32_t instead of uint32_t,
> because these values can be negative. (See officiel sample ./Displaywindow
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> )
>
> Comments welcome

Crashes with:

openexr-images-1.7.0/DisplayWindow/t03.exr

Please use int and unsigned instead of int32_t and uint32_t.

>
> Martin
> Jokyo Images
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale/arm: add ff_hscale_8_to_15_neon

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 12:24:13PM +0200, Matthieu Bouron wrote:
> From: Matthieu Bouron 
> 
> ---
>  libswscale/arm/Makefile   |  6 ++--
>  libswscale/arm/hscale.S   | 70 
> +++
>  libswscale/arm/swscale.c  | 37 +++
>  libswscale/swscale.c  |  2 ++
>  libswscale/swscale_internal.h |  1 +
>  5 files changed, 114 insertions(+), 2 deletions(-)
>  create mode 100644 libswscale/arm/hscale.S
>  create mode 100644 libswscale/arm/swscale.c

tested, works (fate)

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Kyle Swanson]

On Wed, Apr 6, 2016 at 8:09 PM, Carl Eugen Hoyos  wrote:
> Kyle Swanson  ylo.ph> writes:
>
>> Does anyone have any comments about this besides the fact
>> that it links an external library?
>
> It is not ok to add an additional dependency to FFmpeg if the
> features of the new dependency are already available within
> FFmpeg.
> (Note that I cannot judge if this is the case for your patch.)
>

Any issues with breaking out the measurement logic from the ebur128
filter into utility functions? I can take a crack at it if no one
thinks it's a horrible idea...

>
> ___
> 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 1/2 v3] avfilter: add readvitc filter

[Carl Eugen Hoyos]

Tobias Rapp  noa-archive.com> writes:

> > Wouldn't the algorithm also work for GBR?
> 
> If VITC lines are green, yes .

I just tested the sample you uploaded with the following 
command after adding AV_PIX_FMT_GBRP to the supported 
input formats:
$ ffprobe -of compact=p=0 -show_entries frame=pkt_pts:frame_tags 
-f lavfi movie=sample-vitc.avi,readvitc

Output looks identical to yuv420p so I guess white is ok...

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Kyle Swanson]

On Fri, Apr 8, 2016 at 4:07 PM, Kyle Swanson  wrote:
> On Wed, Apr 6, 2016 at 8:09 PM, Carl Eugen Hoyos  wrote:
>> Kyle Swanson  ylo.ph> writes:
>>
>>> Does anyone have any comments about this besides the fact
>>> that it links an external library?
>>
>> It is not ok to add an additional dependency to FFmpeg if the
>> features of the new dependency are already available within
>> FFmpeg.
>> (Note that I cannot judge if this is the case for your patch.)
>>
>
> Any issues with breaking out the measurement logic from the ebur128
> filter into utility functions? I can take a crack at it if no one
> thinks it's a horrible idea...

Or adapt the libebur128 code, which has a couple of nice features and
an MIT license. Obviously the oversampling would have to be rewritten
to use swresample.

>
>>
>> ___
>> 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] hevc: Fix memory leak related to a53_caption data

[Will Kelleher]

On 04/08, Michael Niedermayer wrote:
> 
> > The a53_caption buffer is normally realloc'd when each sei_nal is
> > parsed, and then freed after it gets written to the output frame's
> > side data in hevc_frame_start.
> 
> and if an error happens between it leaks ?
> 

If an error occurred after sei nal parsing but before the data was
written to the output frame's side_data, it would just stay on the
context and get appended to when the following frame's sei nals get
parsed, and then the combined caption data of two frames would be
attached to the second output frame, I think.

> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fffmpeg.org%2fmailman%2flistinfo%2fffmpeg-devel&data=01%7c01%7cwkelleher%40gogoair.com%7c3e503666e20747c6527b08d35fe70a88%7c2e6508518649457ea18abc0264c3b7d0%7c1&sdata=nm%2fxZTmRDJUqGdULOjHD3BWUUjwqIOAtogX7TW%2baMs4%3d

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/shorten: fix decoding on the last frame

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 10:37:28AM +0200, Paul B Mahol wrote:
> Hi,
> 
> patch attached.
> 
> Fixes ticket #4712.

>  shorten.c |4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> b793144094b07fc17e0687139fb7afab983427b8  
> 0001-avcodec-shorten-fix-decoding-of-last-frame.patch
> From e03ee9d75f0f9cb37498bd9ac613c460fadf1145 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol 
> Date: Fri, 8 Apr 2016 10:35:11 +0200
> Subject: [PATCH] avcodec/shorten: fix decoding of last frame
> 
> Previously it would be always discarded.
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/shorten.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)

should be ok


thx

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Michael Niedermayer]

On Fri, Apr 08, 2016 at 04:17:56PM -0500, Will Kelleher wrote:
> On 04/08, Michael Niedermayer wrote:
> > 
> > > The a53_caption buffer is normally realloc'd when each sei_nal is
> > > parsed, and then freed after it gets written to the output frame's
> > > side data in hevc_frame_start.
> > 
> > and if an error happens between it leaks ?
> > 
> 
> If an error occurred after sei nal parsing but before the data was
> written to the output frame's side_data, it would just stay on the
> context and get appended to when the following frame's sei nals get
> parsed, and then the combined caption data of two frames would be
> attached to the second output frame, I think.

consider that this might have been the last frame and theres no next

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Fix memory leak related to a53_caption data

[Will Kelleher]

On 04/08, Michael Niedermayer wrote:
> On Fri, Apr 08, 2016 at 04:17:56PM -0500, Will Kelleher wrote:
> > On 04/08, Michael Niedermayer wrote:
> > > 
> > > > The a53_caption buffer is normally realloc'd when each sei_nal is
> > > > parsed, and then freed after it gets written to the output frame's
> > > > side data in hevc_frame_start.
> > > 
> > > and if an error happens between it leaks ?
> > > 
> > 
> > If an error occurred after sei nal parsing but before the data was
> > written to the output frame's side_data, it would just stay on the
> > context and get appended to when the following frame's sei nals get
> > parsed, and then the combined caption data of two frames would be
> > attached to the second output frame, I think.
> 
> consider that this might have been the last frame and theres no next

The leak is...continuous.  We only noticed it during long running decode
operations because the amount is small, but it definitely adds up.

> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Asymptotically faster algorithms should always be preferred if you have
> asymptotical amounts of data



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fffmpeg.org%2fmailman%2flistinfo%2fffmpeg-devel&data=01%7c01%7cwkelleher%40gogoair.com%7c201d2489d79b4ea6838c08d35ff8e113%7c2e6508518649457ea18abc0264c3b7d0%7c1&sdata=VkOooHUc6od6QXEY1MVqjikRoQrpDIGJZzLLjbfFu9s%3d

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swscale/arm: add ff_hscale_8_to_15_neon

[Matthieu Bouron]

On Fri, Apr 8, 2016 at 10:27 PM, Michael Niedermayer  wrote:

> On Fri, Apr 08, 2016 at 12:24:13PM +0200, Matthieu Bouron wrote:
> > From: Matthieu Bouron 
> >
> > ---
> >  libswscale/arm/Makefile   |  6 ++--
> >  libswscale/arm/hscale.S   | 70
> +++
> >  libswscale/arm/swscale.c  | 37 +++
> >  libswscale/swscale.c  |  2 ++
> >  libswscale/swscale_internal.h |  1 +
> >  5 files changed, 114 insertions(+), 2 deletions(-)
> >  create mode 100644 libswscale/arm/hscale.S
> >  create mode 100644 libswscale/arm/swscale.c
>
> tested, works (fate)
>


Applied with minor changes in the comments.

Thanks,
Matthieu

[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Carl Eugen Hoyos]

Kyle Swanson  ylo.ph> writes:

> Or adapt the libebur128 code, which has a couple of nice features

Did you already explain which of the features is missing 
in current FFmpeg?

Carl Eugen

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add loudnorm

[Hendrik Leppkes]

On Fri, Apr 8, 2016 at 11:15 PM, Kyle Swanson  wrote:
> On Fri, Apr 8, 2016 at 4:07 PM, Kyle Swanson  wrote:
>> On Wed, Apr 6, 2016 at 8:09 PM, Carl Eugen Hoyos  wrote:
>>> Kyle Swanson  ylo.ph> writes:
>>>
 Does anyone have any comments about this besides the fact
 that it links an external library?
>>>
>>> It is not ok to add an additional dependency to FFmpeg if the
>>> features of the new dependency are already available within
>>> FFmpeg.
>>> (Note that I cannot judge if this is the case for your patch.)
>>>
>>
>> Any issues with breaking out the measurement logic from the ebur128
>> filter into utility functions? I can take a crack at it if no one
>> thinks it's a horrible idea...
>
> Or adapt the libebur128 code, which has a couple of nice features and
> an MIT license. Obviously the oversampling would have to be rewritten
> to use swresample.
>

In case you didn't pick up on that particular part, but having the
same basic functionality twice in different code is what the entire
discussion here is trying to avoid.
So if you can reuse the existing ebur128 code that Clement wrote for
the analysis filter that would be the best situation.

Apart from that, the filter looks extremely long for doing a lot of
the same things the r128 filter we have already does, couldn't it just
be build on top of the analysis the existing r128 filter already
provides, and just adjust the audio based on its data?

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for datawindow who exceed display window

[Martin Vignali]

2016-04-08 22:11 GMT+02:00 Paul B Mahol :

> On 4/7/16, Martin Vignali  wrote:
> > Hello,
> >
> > in attach, a patch with some modifications in size/data window
> management,
> > in order to manage
> > negative datawindow/display window, and datawindow who can exceed display
> > window
> >
> > Size of the picture is now set from min and max value of the display
> window
> > (before the patch, xmin, ymin of the display window are ignored (and
> assume
> > to be 0))
> >
> > With the previous patch (fix channel detection), official samples
> > ./scanline/Blobbies.exr
> > can now be correctly decode.
> >
> >
> > DataWindow bigger than display window is a feature of the openExr.
> > It can be use in some softwares, (for example to improve blur quality)
> > Following the official documentation, for display, we need to use the
> > display window only.
> >
> >
> > In this patch, xmin, xmax, ymin, ymax, are now int32_t instead of
> uint32_t,
> > because these values can be negative. (See officiel sample
> ./Displaywindow
> >
> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
> > )
> >
> > Comments welcome
>
> Crashes with:
>
> openexr-images-1.7.0/DisplayWindow/t03.exr
>
> Strange, this sample didn't crash for me (Clang, OS 10.9). Decode it's
still not good after the patch but it's piz compression.
Can you tell me, what configure line, you use ?


> Please use int and unsigned instead of int32_t and uint32_t.
>
>
Where do you think it's better to use int or unsigned int instead of
int32_t, uint_32t ?
Exr Context ?
Decode block ?
Both ?

Thanks for the comments.

Martin
Jokyo Images
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/filters: document testsrc2 source filter

[Lou Logan]

Signed-off-by: Lou Logan 
---
 doc/filters.texi | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 82be06d..b4af424 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14330,7 +14330,8 @@ ffplay -f lavfi 
life=s=300x200:mold=10:r=60:ratio=0.1:death_color=#C83232:life_c
 @anchor{smptebars}
 @anchor{smptehdbars}
 @anchor{testsrc}
-@section allrgb, allyuv, color, haldclutsrc, nullsrc, rgbtestsrc, smptebars, 
smptehdbars, testsrc
+@anchor{testsrc2}
+@section allrgb, allyuv, color, haldclutsrc, nullsrc, rgbtestsrc, smptebars, 
smptehdbars, testsrc, testsrc2
 
 The @code{allrgb} source returns frames of size 4096x4096 of all rgb colors.
 
@@ -14359,6 +14360,10 @@ The @code{testsrc} source generates a test video 
pattern, showing a
 color pattern, a scrolling gradient and a timestamp. This is mainly
 intended for testing purposes.
 
+The @code{testsrc2} source is similar to testsrc, but supports more
+pixel formats instead of just @code{rgb24}. This allows using it as an
+input for other tests without requiring a format conversion.
+
 The sources accept the following parameters:
 
 @table @option
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/exr : add support for datawindow who exceed display window

[Paul B Mahol]

On 4/9/16, Martin Vignali  wrote:
> 2016-04-08 22:11 GMT+02:00 Paul B Mahol :
>
>> On 4/7/16, Martin Vignali  wrote:
>> > Hello,
>> >
>> > in attach, a patch with some modifications in size/data window
>> management,
>> > in order to manage
>> > negative datawindow/display window, and datawindow who can exceed
>> > display
>> > window
>> >
>> > Size of the picture is now set from min and max value of the display
>> window
>> > (before the patch, xmin, ymin of the display window are ignored (and
>> assume
>> > to be 0))
>> >
>> > With the previous patch (fix channel detection), official samples
>> > ./scanline/Blobbies.exr
>> > can now be correctly decode.
>> >
>> >
>> > DataWindow bigger than display window is a feature of the openExr.
>> > It can be use in some softwares, (for example to improve blur quality)
>> > Following the official documentation, for display, we need to use the
>> > display window only.
>> >
>> >
>> > In this patch, xmin, xmax, ymin, ymax, are now int32_t instead of
>> uint32_t,
>> > because these values can be negative. (See officiel sample
>> ./Displaywindow
>> >
>> http://download.savannah.nongnu.org/releases/openexr/openexr-images-1.7.0.tar.gz
>> > )
>> >
>> > Comments welcome
>>
>> Crashes with:
>>
>> openexr-images-1.7.0/DisplayWindow/t03.exr
>>
>> Strange, this sample didn't crash for me (Clang, OS 10.9). Decode it's
> still not good after the patch but it's piz compression.
> Can you tell me, what configure line, you use ?

clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.2.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.5
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.2.1
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.2.1
Candidate multilib: .;@m64
Selected multilib: .;@m64

ffmpeg version git-2016-04-08-1a42beb Copyright (c) 2000-2016 the
FFmpeg developers
  built with clang version 3.7.0 (tags/RELEASE_370/final)
  configuration: --extra-cflags=-I/usr/local/include
--extra-ldflags=-L/usr/local/lib --cc=clang --cxx=clang++ --as=clang
--disable-ffserver --disable-ffplay --disable-indevs --disable-outdevs
--enable-gpl --enable-indev=lavfi --enable-indev=alsa --enable-nonfree
--enable-openssl --enable-outdev=alsa --enable-shared --disable-static
--enable-ladspa --enable-netcdf --enable-fontconfig
--enable-libfreetype --enable-libzimg --enable-libass
--enable-librubberband --disable-stripping --enable-indev=x11grab_xcb
--enable-x11grab --samples=../fate-suite

>
>
>> Please use int and unsigned instead of int32_t and uint32_t.
>>
>>
> Where do you think it's better to use int or unsigned int instead of
> int32_t, uint_32t ?
> Exr Context ?
> Decode block ?
> Both ?

Everywhere.

>
> Thanks for the comments.
>
> Martin
> Jokyo Images
> ___
> 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