Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

2019-04-13 Thread Carl Eugen Hoyos
2019-04-10 21:47 GMT+02:00, Carl Eugen Hoyos :
> 2019-04-09 20:32 GMT+02:00, James Almer :
>> Fixes ticket #7174.
>>
>> Signed-off-by: James Almer 
>> ---
>> This makes what's essentially a non spec compliant
>> stream decodable again with no visual artifacts, and
>> without reintroducing the risk of overflows.
>
> Your patch leads to bit-exact output with the reference
> decoder and old FFmpeg.

This is true for the original sample, the new sample
zNqp.h264 has bit-exact output with old FFmpeg
but not with your patch.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 2/2] avcodec/videotoolbox: add support for full range pixel formats

2019-04-13 Thread der richter
From: Akemi 

---
 fftools/ffmpeg_videotoolbox.c  |  6 --
 libavcodec/videotoolbox.c  | 14 +-
 libavutil/hwcontext_videotoolbox.c | 20 ++--
 libavutil/hwcontext_videotoolbox.h |  6 ++
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/fftools/ffmpeg_videotoolbox.c b/fftools/ffmpeg_videotoolbox.c
index ad6174d3c7..628fb5e32c 100644
--- a/fftools/ffmpeg_videotoolbox.c
+++ b/fftools/ffmpeg_videotoolbox.c
@@ -51,10 +51,12 @@ static int videotoolbox_retrieve_data(AVCodecContext *s, 
AVFrame *frame)
 case kCVPixelFormatType_422YpCbCr8:   vt->tmp_frame->format = 
AV_PIX_FMT_UYVY422; break;
 case kCVPixelFormatType_32BGRA:   vt->tmp_frame->format = 
AV_PIX_FMT_BGRA; break;
 #ifdef kCFCoreFoundationVersionNumber10_7
-case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_NV12; break;
+case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange:
+case kCVPixelFormatType_420YpCbCr8BiPlanarFullRange: vt->tmp_frame->format 
= AV_PIX_FMT_NV12; break;
 #endif
 #if HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
-case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
+case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange:
+case kCVPixelFormatType_420YpCbCr10BiPlanarFullRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
 #endif
 default:
 av_log(NULL, AV_LOG_ERROR,
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 021afd411b..65f9e96d73 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -1082,8 +1082,9 @@ static int videotoolbox_common_init(AVCodecContext *avctx)
 goto fail;
 }

+bool full_range = avctx->color_range == AVCOL_RANGE_JPEG;
 vtctx->vt_ctx->cv_pix_fmt_type =
-av_map_videotoolbox_format_from_pixfmt(hw_frames->sw_format);
+av_map_videotoolbox_format_from_pixfmt2(hw_frames->sw_format, 
full_range);
 if (!vtctx->vt_ctx->cv_pix_fmt_type) {
 av_log(avctx, AV_LOG_ERROR, "Unknown sw_format.\n");
 err = AVERROR(EINVAL);
@@ -1206,14 +1207,15 @@ const AVHWAccel ff_mpeg4_videotoolbox_hwaccel = {
 .priv_data_size = sizeof(VTContext),
 };

-static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt)
+static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt,
+ bool 
full_range)
 {
 AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));

 if (ret) {
 ret->output_callback = videotoolbox_decoder_callback;

-OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt(pix_fmt);
+OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt2(pix_fmt, full_range);
 if (cv_pix_fmt_type == 0) {
 cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
 }
@@ -1225,7 +1227,7 @@ static AVVideotoolboxContext 
*av_videotoolbox_alloc_context_with_pix_fmt(enum AV

 AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
 {
-return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE);
+return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE, false);
 }

 int av_videotoolbox_default_init(AVCodecContext *avctx)
@@ -1235,7 +1237,9 @@ int av_videotoolbox_default_init(AVCodecContext *avctx)

 int av_videotoolbox_default_init2(AVCodecContext *avctx, AVVideotoolboxContext 
*vtctx)
 {
-avctx->hwaccel_context = vtctx ?: 
av_videotoolbox_alloc_context_with_pix_fmt(videotoolbox_best_pixel_format(avctx));
+enum AVPixelFormat pix_fmt = videotoolbox_best_pixel_format(avctx);
+bool full_range = avctx->color_range == AVCOL_RANGE_JPEG;
+avctx->hwaccel_context = vtctx ?: 
av_videotoolbox_alloc_context_with_pix_fmt(pix_fmt, full_range);
 if (!avctx->hwaccel_context)
 return AVERROR(ENOMEM);
 return videotoolbox_start(avctx);
diff --git a/libavutil/hwcontext_videotoolbox.c 
b/libavutil/hwcontext_videotoolbox.c
index 6eac2c0774..bded9873fe 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -34,16 +34,19 @@

 static const struct {
 uint32_t cv_fmt;
+bool full_range;
 enum AVPixelFormat pix_fmt;
 } cv_pix_fmts[] = {
-{ kCVPixelFormatType_420YpCbCr8Planar,  AV_PIX_FMT_YUV420P },
-{ kCVPixelFormatType_422YpCbCr8,AV_PIX_FMT_UYVY422 },
-{ kCVPixelFormatType_32BGRA,AV_PIX_FMT_BGRA },
+{ kCVPixelFormatType_420YpCbCr8Planar,  false, 
AV_PIX_FMT_YUV420P },
+{ kCVPixelFormatType_422YpCbCr8,false, 
AV_PIX_FMT_UYVY422 },
+{ kCVPixelFormatType_32BGRA,false, AV_PIX_FMT_BGRA 
},
 #ifdef kCFCoreFoundationVersionNumber10_7
-{ kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange,  AV_PIX_FMT_NV12 },

[FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: add support for 10bit pixel format

2019-04-13 Thread der richter
From: fumoboy007 

this patch was originally posted on issue #7704 and was slightly
adjusted to check for the availability of the pixel format.
---
 configure  |  2 ++
 fftools/ffmpeg_videotoolbox.c  |  3 +++
 libavcodec/videotoolbox.c  | 32 +-
 libavutil/hwcontext_videotoolbox.c |  3 +++
 4 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 331393f8d5..a89da70aab 100755
--- a/configure
+++ b/configure
@@ -2253,6 +2253,7 @@ TOOLCHAIN_FEATURES="

 TYPES_LIST="
 kCMVideoCodecType_HEVC
+kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
 socklen_t
 struct_addrinfo
 struct_group_source_req
@@ -6012,6 +6013,7 @@ enabled avfoundation && {
 enabled videotoolbox && {
 check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
 check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
+check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
 }

 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
diff --git a/fftools/ffmpeg_videotoolbox.c b/fftools/ffmpeg_videotoolbox.c
index b820aec017..ad6174d3c7 100644
--- a/fftools/ffmpeg_videotoolbox.c
+++ b/fftools/ffmpeg_videotoolbox.c
@@ -52,6 +52,9 @@ static int videotoolbox_retrieve_data(AVCodecContext *s, 
AVFrame *frame)
 case kCVPixelFormatType_32BGRA:   vt->tmp_frame->format = 
AV_PIX_FMT_BGRA; break;
 #ifdef kCFCoreFoundationVersionNumber10_7
 case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_NV12; break;
+#endif
+#if HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
+case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
 #endif
 default:
 av_log(NULL, AV_LOG_ERROR,
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index fb3501f413..021afd411b 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -26,6 +26,7 @@
 #include "vt_internal.h"
 #include "libavutil/avutil.h"
 #include "libavutil/hwcontext.h"
+#include "libavutil/pixdesc.h"
 #include "bytestream.h"
 #include "decode.h"
 #include "h264dec.h"
@@ -1020,6 +1021,17 @@ static int videotoolbox_uninit(AVCodecContext *avctx)
 return 0;
 }

+static enum AVPixelFormat videotoolbox_best_pixel_format(AVCodecContext 
*avctx) {
+const AVPixFmtDescriptor *descriptor = av_pix_fmt_desc_get(avctx->pix_fmt);
+if (!descriptor)
+return AV_PIX_FMT_NV12; // same as av_videotoolbox_alloc_context()
+
+int depth = descriptor->comp[0].depth;
+if (depth > 8) {
+return AV_PIX_FMT_P010;
+}
+}
+
 static int videotoolbox_common_init(AVCodecContext *avctx)
 {
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
@@ -1053,7 +1065,7 @@ static int videotoolbox_common_init(AVCodecContext *avctx)

 hw_frames = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
 hw_frames->format = AV_PIX_FMT_VIDEOTOOLBOX;
-hw_frames->sw_format = AV_PIX_FMT_NV12; // same as 
av_videotoolbox_alloc_context()
+hw_frames->sw_format = videotoolbox_best_pixel_format(avctx);
 hw_frames->width = avctx->width;
 hw_frames->height = avctx->height;

@@ -1097,7 +1109,7 @@ static int videotoolbox_frame_params(AVCodecContext 
*avctx,
 frames_ctx->format= AV_PIX_FMT_VIDEOTOOLBOX;
 frames_ctx->width = avctx->coded_width;
 frames_ctx->height= avctx->coded_height;
-frames_ctx->sw_format = AV_PIX_FMT_NV12;
+frames_ctx->sw_format = videotoolbox_best_pixel_format(avctx);

 return 0;
 }
@@ -1194,18 +1206,28 @@ const AVHWAccel ff_mpeg4_videotoolbox_hwaccel = {
 .priv_data_size = sizeof(VTContext),
 };

-AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
+static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt)
 {
 AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));

 if (ret) {
 ret->output_callback = videotoolbox_decoder_callback;
-ret->cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
+
+OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt(pix_fmt);
+if (cv_pix_fmt_type == 0) {
+cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
+}
+ret->cv_pix_fmt_type = cv_pix_fmt_type;
 }

 return ret;
 }

+AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
+{
+return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE);
+}
+
 int av_videotoolbox_default_init(AVCodecContext *avctx)
 {
 return av_videotoolbox_default_init2(avctx, NULL);
@@ -1213,7 +1235,7 @@ int av_videotoolbox_default_init(AVCodecContext *avctx)

 int av_videotoolbox_default_init2(AVCodecContext *avctx, AVVideotoolboxContext

[FFmpeg-devel] [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

2019-04-13 Thread Gyan
Will be helpful for correct result in filters that paint like 
fillborders/drawbox or those using drawutils.


Gyan
From 9c83440a0ac048a1dcb0762b85adbce5a58e0939 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sat, 13 Apr 2019 17:01:09 +0530
Subject: [PATCH] avutil/colorspace: add macros for RGB->YUV BT.709

---
 libavutil/colorspace.h | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/libavutil/colorspace.h b/libavutil/colorspace.h
index d0be8cb99a..73d51cad47 100644
--- a/libavutil/colorspace.h
+++ b/libavutil/colorspace.h
@@ -119,4 +119,31 @@ static inline int C_JPEG_TO_CCIR(int y) {
 (((FIX(0.5) * r1 - FIX(0.41869) * g1 - \
FIX(0.08131) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
 
+// Derived from ITU-R BT.709-6 (06/2015) Item 3.5
+// https://www.itu.int/rec/R-REC-BT.709-6-201506-I/en
+
+#define RGB_TO_Y_BT709(r, g, b) \
+((FIX(0.21260*219.0/255.0) * (r) + FIX(0.71520*219.0/255.0) * (g) + \
+  FIX(0.07220*219.0/255.0) * (b) + (ONE_HALF + (16 << SCALEBITS))) >> 
SCALEBITS)
+
+#define RGB_TO_U_BT709(r1, g1, b1, shift)\
+(((- FIX(0.11457*224.0/255.0) * r1 - FIX(0.38543*224.0/255.0) * g1 + \
+ FIX(0.5*224.0/255.0) * b1 + (ONE_HALF << shift) - 1) >> (SCALEBITS + 
shift)) + 128)
+
+#define RGB_TO_V_BT709(r1, g1, b1, shift)\
+(((FIX(0.5*224.0/255.0) * r1 - FIX(0.45415*224.0/255.0) * g1 -   \
+   FIX(0.04585*224.0/255.0) * b1 + (ONE_HALF << shift) - 1) >> (SCALEBITS + 
shift)) + 128)
+
+#define RGB_TO_Y_BT709_FULL(r, g, b) \
+(FFMIN((FIX(0.21260) * (r) + FIX(0.71520) * (g) + \
+  FIX(0.07220) * (b) + (ONE_HALF)) >> SCALEBITS, 255))
+
+#define RGB_TO_U_BT709_FULL(r1, g1, b1)\
+(((- FIX(0.11457) * r1 - FIX(0.38543) * g1 + \
+ FIX(0.5) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
+
+#define RGB_TO_V_BT709_FULL(r1, g1, b1)\
+(((FIX(0.5) * r1 - FIX(0.45415) * g1 - \
+   FIX(0.04585) * b1 + (ONE_HALF) - 1) >> (SCALEBITS)) + 128)
+
 #endif /* AVUTIL_COLORSPACE_H */
-- 
2.19.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

2019-04-13 Thread Eugene Lyapustin
Hello,

This patch is a qualification task on 360 video filter.
I took a filter originally written by Paul B Mahol, and which was modified last 
year by another student. The filter had a lot of hardcoded conversions between 
formats, and it would be a pain to extend it with new ones. So I unified the 
remap calculation procedure. Now all formats only need functions to convert 
format coordinates to cartesian coordinates and vice versa. 

Regards,
Eugene Lyapustin

-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

2019-04-13 Thread Eugene Lyapustin
Add filter for conversion between various panorama formats.
Supported formats: equirectangular, cubemap 3x2, cubemap 6x1

Contributions:

unify remap calculation procedure
add option for interpolation method

Signed-off-by: Eugene Lyapustin 

---

use bilinear from cubemap to equirectangular
Change cube faces order to match Youtube's
avfilter: add convertion to/from cubemap 6x1

Signed-off-by: Hazem Ashmawy 

---

avfilter: add panorama filter

Signed-off-by: Paul B Mahol 

Signed-off-by: Eugene Lyapustin 
---
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_panorama.c | 637 ++
 3 files changed, 639 insertions(+)
 create mode 100644 libavfilter/vf_panorama.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..3c272da7b2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -307,6 +307,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
 OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
 OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o framesync.o
+OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
 OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
 OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
 OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..f49c0a40e0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -292,6 +292,7 @@ extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
 extern AVFilter ff_vf_palettegen;
 extern AVFilter ff_vf_paletteuse;
+extern AVFilter ff_vf_panorama;
 extern AVFilter ff_vf_perms;
 extern AVFilter ff_vf_perspective;
 extern AVFilter ff_vf_phase;
diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
new file mode 100644
index 00..34f02b0fa3
--- /dev/null
+++ b/libavfilter/vf_panorama.c
@@ -0,0 +1,637 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum Projections {
+EQUIRECTANGULAR,
+CUBEMAP_6_1,
+CUBEMAP_3_2,
+NB_PROJECTIONS,
+};
+
+enum InterpMethod {
+  NEAREST,
+  BILINEAR,
+  NB_INTERP_METHODS,
+};
+
+enum Faces {
+RIGHT,
+LEFT,
+TOP,
+DOWN,
+FRONT,
+BACK,
+};
+
+struct XYRemap {
+int vi, ui;
+int v2, u2;
+double a, b, c, d;
+};
+
+typedef struct PanoramaContext {
+const AVClass *class;
+int in, out;
+int interp;
+
+int planewidth[4], planeheight[4];
+int inplanewidth[4], inplaneheight[4];
+int nb_planes;
+
+struct XYRemap *remap[4];
+
+int (*panorama)(struct PanoramaContext *s,
+const uint8_t *src, uint8_t *dst,
+int width, int height,
+int in_linesize, int out_linesize,
+const struct XYRemap *remap);
+} PanoramaContext;
+
+#define OFFSET(x) offsetof(PanoramaContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption panorama_options[] = {
+{"input", "set input projection", OFFSET(in), AV_OPT_TYPE_INT, 
  {.i64=EQUIRECTANGULAR}, 0,NB_PROJECTIONS-1, FLAGS, "in" },
+{"e", "equirectangular",   0, 
AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0,   0, FLAGS, "in" 
},
+{ "c6x1", "cubemap",   0, 
AV_OPT_TYPE_CONST, {.i64=CUBEMAP_6_1}, 0,   0, FLAGS, "in" 
},
+{ "c3x2", "cubemap",   0, 
AV_OPT_TYPE_CONST, {.i64=CUBEMAP_3_2}, 0,   0, FLAGS, "in" 
},
+{   "output", "set output projection",   OFFSET(out), AV_OPT_TYPE_INT, 
  {.i64=CUBEMAP_3_2}, 0,NB_PROJECTIONS-1, FLAGS, "out" },
+{"e", "equirectangular",   0, 
AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0, 

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolbox: add support for 10bit pixel format

2019-04-13 Thread Aman Gupta
On Sat, Apr 13, 2019 at 3:25 AM der richter  wrote:

> From: fumoboy007 
>
> this patch was originally posted on issue #7704 and was slightly
> adjusted to check for the availability of the pixel format.
> ---
>  configure  |  2 ++
>  fftools/ffmpeg_videotoolbox.c  |  3 +++
>  libavcodec/videotoolbox.c  | 32 +-
>  libavutil/hwcontext_videotoolbox.c |  3 +++
>  4 files changed, 35 insertions(+), 5 deletions(-)
>
> diff --git a/configure b/configure
> index 331393f8d5..a89da70aab 100755
> --- a/configure
> +++ b/configure
> @@ -2253,6 +2253,7 @@ TOOLCHAIN_FEATURES="
>
>  TYPES_LIST="
>  kCMVideoCodecType_HEVC
> +kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
>  socklen_t
>  struct_addrinfo
>  struct_group_source_req
> @@ -6012,6 +6013,7 @@ enabled avfoundation && {
>  enabled videotoolbox && {
>  check_lib coreservices CoreServices/CoreServices.h
> UTGetOSTypeFromString "-framework CoreServices"
>  check_func_headers CoreMedia/CMFormatDescription.h
> kCMVideoCodecType_HEVC "-framework CoreMedia"
> +check_func_headers CoreVideo/CVPixelBuffer.h
> kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
>  }
>
>  check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
> diff --git a/fftools/ffmpeg_videotoolbox.c b/fftools/ffmpeg_videotoolbox.c
> index b820aec017..ad6174d3c7 100644
> --- a/fftools/ffmpeg_videotoolbox.c
> +++ b/fftools/ffmpeg_videotoolbox.c
> @@ -52,6 +52,9 @@ static int videotoolbox_retrieve_data(AVCodecContext *s,
> AVFrame *frame)
>  case kCVPixelFormatType_32BGRA:   vt->tmp_frame->format =
> AV_PIX_FMT_BGRA; break;
>  #ifdef kCFCoreFoundationVersionNumber10_7
>  case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange:
> vt->tmp_frame->format = AV_PIX_FMT_NV12; break;
> +#endif
> +#if HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
> +case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange:
> vt->tmp_frame->format = AV_PIX_FMT_P010; break;
>  #endif
>  default:
>  av_log(NULL, AV_LOG_ERROR,
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index fb3501f413..021afd411b 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -26,6 +26,7 @@
>  #include "vt_internal.h"
>  #include "libavutil/avutil.h"
>  #include "libavutil/hwcontext.h"
> +#include "libavutil/pixdesc.h"
>  #include "bytestream.h"
>  #include "decode.h"
>  #include "h264dec.h"
> @@ -1020,6 +1021,17 @@ static int videotoolbox_uninit(AVCodecContext
> *avctx)
>  return 0;
>  }
>
> +static enum AVPixelFormat videotoolbox_best_pixel_format(AVCodecContext
> *avctx) {
> +const AVPixFmtDescriptor *descriptor =
> av_pix_fmt_desc_get(avctx->pix_fmt);
> +if (!descriptor)
> +return AV_PIX_FMT_NV12; // same as av_videotoolbox_alloc_context()
> +
> +int depth = descriptor->comp[0].depth;
> +if (depth > 8) {
> +return AV_PIX_FMT_P010;
> +}


Need a final fall-through return before the end of the function.


> +}
> +
>  static int videotoolbox_common_init(AVCodecContext *avctx)
>  {
>  VTContext *vtctx = avctx->internal->hwaccel_priv_data;
> @@ -1053,7 +1065,7 @@ static int videotoolbox_common_init(AVCodecContext
> *avctx)
>
>  hw_frames = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
>  hw_frames->format = AV_PIX_FMT_VIDEOTOOLBOX;
> -hw_frames->sw_format = AV_PIX_FMT_NV12; // same as
> av_videotoolbox_alloc_context()
> +hw_frames->sw_format = videotoolbox_best_pixel_format(avctx);
>  hw_frames->width = avctx->width;
>  hw_frames->height = avctx->height;
>
> @@ -1097,7 +1109,7 @@ static int videotoolbox_frame_params(AVCodecContext
> *avctx,
>  frames_ctx->format= AV_PIX_FMT_VIDEOTOOLBOX;
>  frames_ctx->width = avctx->coded_width;
>  frames_ctx->height= avctx->coded_height;
> -frames_ctx->sw_format = AV_PIX_FMT_NV12;
> +frames_ctx->sw_format = videotoolbox_best_pixel_format(avctx);
>
>  return 0;
>  }
> @@ -1194,18 +1206,28 @@ const AVHWAccel ff_mpeg4_videotoolbox_hwaccel = {
>  .priv_data_size = sizeof(VTContext),
>  };
>
> -AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
> +static AVVideotoolboxContext
> *av_videotoolbox_alloc_context_with_pix_fmt(enum AVPixelFormat pix_fmt)
>  {
>  AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));
>
>  if (ret) {
>  ret->output_callback = videotoolbox_decoder_callback;
> -ret->cv_pix_fmt_type =
> kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
> +
> +OSType cv_pix_fmt_type =
> av_map_videotoolbox_format_from_pixfmt(pix_fmt);
> +if (cv_pix_fmt_type == 0) {
> +cv_pix_fmt_type =
> kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
> +}
> +ret->cv_pix_fmt_type = cv_pix_fmt_type;
>  }
>
>  return ret;
>  }
>
> +AVVideotoolboxContext *av_videotoolbox_alloc_con

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

2019-04-13 Thread James Almer
On 4/13/2019 5:44 AM, Carl Eugen Hoyos wrote:
> 2019-04-10 21:47 GMT+02:00, Carl Eugen Hoyos :
>> 2019-04-09 20:32 GMT+02:00, James Almer :
>>> Fixes ticket #7174.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> This makes what's essentially a non spec compliant
>>> stream decodable again with no visual artifacts, and
>>> without reintroducing the risk of overflows.
>>
>> Your patch leads to bit-exact output with the reference
>> decoder and old FFmpeg.
> 
> This is true for the original sample, the new sample
> zNqp.h264 has bit-exact output with old FFmpeg
> but not with your patch.

Where can i get this sample? Perhaps clipping the bogus value will make
it bitexact.

It would be nice to know what the reference decoder does, for that
matter. If it's bothering like us to check and handle this out of spec
values, or if they do like we used to and just pass them through.

> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] lavf/webm_chunk: Respect buffer size

2019-04-13 Thread Andreas Rheinhardt via ffmpeg-devel
The last argument of av_strlcpy is supposed to contain the size of the
destination buffer, but it was filled with the size of the source
string, effectively negating its very purpose.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/webm_chunk.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index ec1ec4bf91..2c99753b5b 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -96,7 +96,7 @@ static int get_chunk_filename(AVFormatContext *s, int 
is_header, char *filename)
 av_log(oc, AV_LOG_ERROR, "No header filename provided\n");
 return AVERROR(EINVAL);
 }
-av_strlcpy(filename, wc->header_filename, strlen(wc->header_filename) 
+ 1);
+av_strlcpy(filename, wc->header_filename, MAX_FILENAME_SIZE);
 } else {
 if (av_get_frame_filename(filename, MAX_FILENAME_SIZE,
   s->url, wc->chunk_index - 1) < 0) {
-- 
2.19.2

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] lavf/webm_chunk: Fix NULL dereference

2019-04-13 Thread Andreas Rheinhardt
The earlier version of the webm_chunk muxer had several bugs:

1. If the first packet of an audio stream didn't have a PTS of zero,
then no chunk will be started before a packet is delivered to the
underlying Matroska/WebM muxer, i.e. the AVFormatContext used to write
these packets had a NULL as AVIOContext for output. This is behind the
crash in ticket #5752.

2. If an error happens during writing a packet, the underlyimg
Matroska/WebM muxer context is freed. This leads to a use-after-free
coupled with a double-free in webm_chunk_write_trailer (which supposes
that the underlying AVFormatContext is still valid).

3. Even when no error occurs at all, webm_chunk_write_trailer is still
buggy: After the underlying Matroska/WebM muxer has written its trailer,
ending the chunk implicitly flushes it again which is illegal at this
point.

These bugs have been fixed.

Fixes #5752.

Signed-off-by: Andreas Rheinhardt 
---
There is one problem that could not be completely solved: If there is no
output AVIOContext when writing the trailer and opening one fails, then
I can't write the Matroska/WebM trailer (as this might lead to NULL
pointer dereference (something might need to be written and the
AVIOContext for writing is not existing). And in this case a bit of
memory (like the tracks that is part of MatroskaMuxContest) will leak.
But this only happens in the very unlikely scenario that there isn't
enough memory to open a dynamic buffer.
 libavformat/webm_chunk.c | 44 +---
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index 2c99753b5b..391fee721a 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -168,7 +168,7 @@ static int chunk_start(AVFormatContext *s)
 return 0;
 }
 
-static int chunk_end(AVFormatContext *s)
+static int chunk_end(AVFormatContext *s, int flush)
 {
 WebMChunkContext *wc = s->priv_data;
 AVFormatContext *oc = wc->avf;
@@ -179,11 +179,14 @@ static int chunk_end(AVFormatContext *s)
 char filename[MAX_FILENAME_SIZE];
 AVDictionary *options = NULL;
 
-if (wc->chunk_start_index == wc->chunk_index)
+if (!oc->pb)
 return 0;
-// Flush the cluster in WebM muxer.
-oc->oformat->write_packet(oc, NULL);
+
+if (flush)
+// Flush the cluster in WebM muxer.
+oc->oformat->write_packet(oc, NULL);
 buffer_size = avio_close_dyn_buf(oc->pb, &buffer);
+oc->pb = NULL;
 ret = get_chunk_filename(s, 0, filename);
 if (ret < 0)
 goto fail;
@@ -194,7 +197,6 @@ static int chunk_end(AVFormatContext *s)
 goto fail;
 avio_write(pb, buffer, buffer_size);
 ff_format_io_close(s, &pb);
-oc->pb = NULL;
 fail:
 av_dict_free(&options);
 av_free(buffer);
@@ -216,27 +218,19 @@ static int webm_chunk_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 
 // For video, a new chunk is started only on key frames. For audio, a new
-// chunk is started based on chunk_duration.
-if ((st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
+// chunk is started based on chunk_duration. Also, a new chunk is started
+// unconditionally if there is no currently open chunk.
+if (!oc->pb || (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO &&
  (pkt->flags & AV_PKT_FLAG_KEY)) ||
 (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
- (pkt->pts == 0 || wc->duration_written >= wc->chunk_duration))) {
+ wc->duration_written >= wc->chunk_duration)) {
 wc->duration_written = 0;
-if ((ret = chunk_end(s)) < 0 || (ret = chunk_start(s)) < 0) {
-goto fail;
+if ((ret = chunk_end(s, 1)) < 0 || (ret = chunk_start(s)) < 0) {
+return ret;
 }
 }
 
 ret = oc->oformat->write_packet(oc, pkt);
-if (ret < 0)
-goto fail;
-
-fail:
-if (ret < 0) {
-oc->streams = NULL;
-oc->nb_streams = 0;
-avformat_free_context(oc);
-}
 
 return ret;
 }
@@ -245,12 +239,20 @@ static int webm_chunk_write_trailer(AVFormatContext *s)
 {
 WebMChunkContext *wc = s->priv_data;
 AVFormatContext *oc = wc->avf;
+int ret;
+
+if (!oc->pb) {
+ret = chunk_start(s);
+if (ret < 0)
+goto fail;
+}
 oc->oformat->write_trailer(oc);
-chunk_end(s);
+ret = chunk_end(s, 0);
+fail:
 oc->streams = NULL;
 oc->nb_streams = 0;
 avformat_free_context(oc);
-return 0;
+return ret;
 }
 
 #define OFFSET(x) offsetof(WebMChunkContext, x)
-- 
2.19.2

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

2019-04-13 Thread James Almer
On 4/13/2019 10:28 AM, James Almer wrote:
> On 4/13/2019 5:44 AM, Carl Eugen Hoyos wrote:
>> 2019-04-10 21:47 GMT+02:00, Carl Eugen Hoyos :
>>> 2019-04-09 20:32 GMT+02:00, James Almer :
 Fixes ticket #7174.

 Signed-off-by: James Almer 
 ---
 This makes what's essentially a non spec compliant
 stream decodable again with no visual artifacts, and
 without reintroducing the risk of overflows.
>>>
>>> Your patch leads to bit-exact output with the reference
>>> decoder and old FFmpeg.
>>
>> This is true for the original sample, the new sample
>> zNqp.h264 has bit-exact output with old FFmpeg
>> but not with your patch.
> 
> Where can i get this sample? Perhaps clipping the bogus value will make
> it bitexact.
> 
> It would be nice to know what the reference decoder does, for that
> matter. If it's bothering like us to check and handle this out of spec
> values, or if they do like we used to and just pass them through.

Found it and tested the above, and with clipping it still doesn't seem
to be bitexact with old ffmpeg.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

2019-04-13 Thread Carl Eugen Hoyos
2019-04-13 15:28 GMT+02:00, James Almer :

> It would be nice to know what the reference decoder does

That's why I told you;-)

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] lavf/webm_chunk: Correct duration if start time > 0

2019-04-13 Thread Andreas Rheinhardt via ffmpeg-devel
Up until now, it was simply presumed that the first packet had a pts of
zero; otherwise the duration of the first chunk was wrong.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/webm_chunk.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavformat/webm_chunk.c b/libavformat/webm_chunk.c
index 391fee721a..d45ebfb1e5 100644
--- a/libavformat/webm_chunk.c
+++ b/libavformat/webm_chunk.c
@@ -52,7 +52,7 @@ typedef struct WebMChunkContext {
 int chunk_index;
 char *http_method;
 uint64_t duration_written;
-int prev_pts;
+int64_t prev_pts;
 ff_const59 AVOutputFormat *oformat;
 AVFormatContext *avf;
 } WebMChunkContext;
@@ -124,6 +124,7 @@ static int webm_chunk_write_header(AVFormatContext *s)
 wc->oformat = av_guess_format("webm", s->url, "video/webm");
 if (!wc->oformat)
 return AVERROR_MUXER_NOT_FOUND;
+wc->prev_pts = AV_NOPTS_VALUE;
 
 ret = chunk_mux_init(s);
 if (ret < 0)
@@ -211,9 +212,10 @@ static int webm_chunk_write_packet(AVFormatContext *s, 
AVPacket *pkt)
 int ret;
 
 if (st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO) {
-wc->duration_written += av_rescale_q(pkt->pts - wc->prev_pts,
- st->time_base,
- (AVRational) {1, 1000});
+if (wc->prev_pts != AV_NOPTS_VALUE)
+wc->duration_written += av_rescale_q(pkt->pts - wc->prev_pts,
+ st->time_base,
+ (AVRational) {1, 1000});
 wc->prev_pts = pkt->pts;
 }
 
-- 
2.19.2

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/h264: error out on ff_h264_pred_weight_table() only if strict spec compliance is requested

2019-04-13 Thread James Almer
On 4/13/2019 10:46 AM, Carl Eugen Hoyos wrote:
> 2019-04-13 15:28 GMT+02:00, James Almer :
> 
>> It would be nice to know what the reference decoder does
> 
> That's why I told you;-)

I must have missed it. Outside of saying its output is bitexact for the
first sample as ffmpeg after my patch, i don't think you mentioned
what's its behavior for these out of spec values.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3 1/2] avcodec/videotoolbox: add support for 10bit pixel format

2019-04-13 Thread der richter
From: fumoboy007 

this patch was originally posted on issue #7704 and was slightly
adjusted to check for the availability of the pixel format.
---
 configure  |  2 ++
 fftools/ffmpeg_videotoolbox.c  |  3 +++
 libavcodec/videotoolbox.c  | 34 +-
 libavutil/hwcontext_videotoolbox.c |  3 +++
 4 files changed, 37 insertions(+), 5 deletions(-)

diff --git a/configure b/configure
index 331393f8d5..a89da70aab 100755
--- a/configure
+++ b/configure
@@ -2253,6 +2253,7 @@ TOOLCHAIN_FEATURES="

 TYPES_LIST="
 kCMVideoCodecType_HEVC
+kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange
 socklen_t
 struct_addrinfo
 struct_group_source_req
@@ -6012,6 +6013,7 @@ enabled avfoundation && {
 enabled videotoolbox && {
 check_lib coreservices CoreServices/CoreServices.h UTGetOSTypeFromString 
"-framework CoreServices"
 check_func_headers CoreMedia/CMFormatDescription.h kCMVideoCodecType_HEVC 
"-framework CoreMedia"
+check_func_headers CoreVideo/CVPixelBuffer.h 
kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange "-framework CoreVideo"
 }

 check_struct "sys/time.h sys/resource.h" "struct rusage" ru_maxrss
diff --git a/fftools/ffmpeg_videotoolbox.c b/fftools/ffmpeg_videotoolbox.c
index b820aec017..ad6174d3c7 100644
--- a/fftools/ffmpeg_videotoolbox.c
+++ b/fftools/ffmpeg_videotoolbox.c
@@ -52,6 +52,9 @@ static int videotoolbox_retrieve_data(AVCodecContext *s, 
AVFrame *frame)
 case kCVPixelFormatType_32BGRA:   vt->tmp_frame->format = 
AV_PIX_FMT_BGRA; break;
 #ifdef kCFCoreFoundationVersionNumber10_7
 case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_NV12; break;
+#endif
+#if HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
+case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
 #endif
 default:
 av_log(NULL, AV_LOG_ERROR,
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index fb3501f413..c718e82cc5 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -26,6 +26,7 @@
 #include "vt_internal.h"
 #include "libavutil/avutil.h"
 #include "libavutil/hwcontext.h"
+#include "libavutil/pixdesc.h"
 #include "bytestream.h"
 #include "decode.h"
 #include "h264dec.h"
@@ -1020,6 +1021,19 @@ static int videotoolbox_uninit(AVCodecContext *avctx)
 return 0;
 }

+static enum AVPixelFormat videotoolbox_best_pixel_format(AVCodecContext 
*avctx) {
+const AVPixFmtDescriptor *descriptor = av_pix_fmt_desc_get(avctx->pix_fmt);
+if (!descriptor)
+return AV_PIX_FMT_NV12; // same as av_videotoolbox_alloc_context()
+
+int depth = descriptor->comp[0].depth;
+if (depth > 8) {
+return AV_PIX_FMT_P010;
+}
+
+return AV_PIX_FMT_NV12;
+}
+
 static int videotoolbox_common_init(AVCodecContext *avctx)
 {
 VTContext *vtctx = avctx->internal->hwaccel_priv_data;
@@ -1053,7 +1067,7 @@ static int videotoolbox_common_init(AVCodecContext *avctx)

 hw_frames = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
 hw_frames->format = AV_PIX_FMT_VIDEOTOOLBOX;
-hw_frames->sw_format = AV_PIX_FMT_NV12; // same as 
av_videotoolbox_alloc_context()
+hw_frames->sw_format = videotoolbox_best_pixel_format(avctx);
 hw_frames->width = avctx->width;
 hw_frames->height = avctx->height;

@@ -1097,7 +,7 @@ static int videotoolbox_frame_params(AVCodecContext 
*avctx,
 frames_ctx->format= AV_PIX_FMT_VIDEOTOOLBOX;
 frames_ctx->width = avctx->coded_width;
 frames_ctx->height= avctx->coded_height;
-frames_ctx->sw_format = AV_PIX_FMT_NV12;
+frames_ctx->sw_format = videotoolbox_best_pixel_format(avctx);

 return 0;
 }
@@ -1194,18 +1208,28 @@ const AVHWAccel ff_mpeg4_videotoolbox_hwaccel = {
 .priv_data_size = sizeof(VTContext),
 };

-AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
+static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt)
 {
 AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));

 if (ret) {
 ret->output_callback = videotoolbox_decoder_callback;
-ret->cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
+
+OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt(pix_fmt);
+if (cv_pix_fmt_type == 0) {
+cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
+}
+ret->cv_pix_fmt_type = cv_pix_fmt_type;
 }

 return ret;
 }

+AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
+{
+return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE);
+}
+
 int av_videotoolbox_default_init(AVCodecContext *avctx)
 {
 return av_videotoolbox_default_init2(avctx, NULL);
@@ -1213,7 +1237,7 @@ int av_videotoolbox_default_init(AVCodecContext *avctx)

 int av_videotoolbox_default_init2(AVCodecContex

[FFmpeg-devel] [PATCH v3 2/2] avcodec/videotoolbox: add support for full range pixel formats

2019-04-13 Thread der richter
From: Akemi 

---
 fftools/ffmpeg_videotoolbox.c  |  6 --
 libavcodec/videotoolbox.c  | 14 +-
 libavutil/hwcontext_videotoolbox.c | 20 ++--
 libavutil/hwcontext_videotoolbox.h |  6 ++
 4 files changed, 33 insertions(+), 13 deletions(-)

diff --git a/fftools/ffmpeg_videotoolbox.c b/fftools/ffmpeg_videotoolbox.c
index ad6174d3c7..628fb5e32c 100644
--- a/fftools/ffmpeg_videotoolbox.c
+++ b/fftools/ffmpeg_videotoolbox.c
@@ -51,10 +51,12 @@ static int videotoolbox_retrieve_data(AVCodecContext *s, 
AVFrame *frame)
 case kCVPixelFormatType_422YpCbCr8:   vt->tmp_frame->format = 
AV_PIX_FMT_UYVY422; break;
 case kCVPixelFormatType_32BGRA:   vt->tmp_frame->format = 
AV_PIX_FMT_BGRA; break;
 #ifdef kCFCoreFoundationVersionNumber10_7
-case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_NV12; break;
+case kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange:
+case kCVPixelFormatType_420YpCbCr8BiPlanarFullRange: vt->tmp_frame->format 
= AV_PIX_FMT_NV12; break;
 #endif
 #if HAVE_KCVPIXELFORMATTYPE_420YPCBCR10BIPLANARVIDEORANGE
-case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
+case kCVPixelFormatType_420YpCbCr10BiPlanarVideoRange:
+case kCVPixelFormatType_420YpCbCr10BiPlanarFullRange: 
vt->tmp_frame->format = AV_PIX_FMT_P010; break;
 #endif
 default:
 av_log(NULL, AV_LOG_ERROR,
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index c718e82cc5..b3b38dbde3 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -1084,8 +1084,9 @@ static int videotoolbox_common_init(AVCodecContext *avctx)
 goto fail;
 }

+bool full_range = avctx->color_range == AVCOL_RANGE_JPEG;
 vtctx->vt_ctx->cv_pix_fmt_type =
-av_map_videotoolbox_format_from_pixfmt(hw_frames->sw_format);
+av_map_videotoolbox_format_from_pixfmt2(hw_frames->sw_format, 
full_range);
 if (!vtctx->vt_ctx->cv_pix_fmt_type) {
 av_log(avctx, AV_LOG_ERROR, "Unknown sw_format.\n");
 err = AVERROR(EINVAL);
@@ -1208,14 +1209,15 @@ const AVHWAccel ff_mpeg4_videotoolbox_hwaccel = {
 .priv_data_size = sizeof(VTContext),
 };

-static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt)
+static AVVideotoolboxContext *av_videotoolbox_alloc_context_with_pix_fmt(enum 
AVPixelFormat pix_fmt,
+ bool 
full_range)
 {
 AVVideotoolboxContext *ret = av_mallocz(sizeof(*ret));

 if (ret) {
 ret->output_callback = videotoolbox_decoder_callback;

-OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt(pix_fmt);
+OSType cv_pix_fmt_type = 
av_map_videotoolbox_format_from_pixfmt2(pix_fmt, full_range);
 if (cv_pix_fmt_type == 0) {
 cv_pix_fmt_type = kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange;
 }
@@ -1227,7 +1229,7 @@ static AVVideotoolboxContext 
*av_videotoolbox_alloc_context_with_pix_fmt(enum AV

 AVVideotoolboxContext *av_videotoolbox_alloc_context(void)
 {
-return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE);
+return av_videotoolbox_alloc_context_with_pix_fmt(AV_PIX_FMT_NONE, false);
 }

 int av_videotoolbox_default_init(AVCodecContext *avctx)
@@ -1237,7 +1239,9 @@ int av_videotoolbox_default_init(AVCodecContext *avctx)

 int av_videotoolbox_default_init2(AVCodecContext *avctx, AVVideotoolboxContext 
*vtctx)
 {
-avctx->hwaccel_context = vtctx ?: 
av_videotoolbox_alloc_context_with_pix_fmt(videotoolbox_best_pixel_format(avctx));
+enum AVPixelFormat pix_fmt = videotoolbox_best_pixel_format(avctx);
+bool full_range = avctx->color_range == AVCOL_RANGE_JPEG;
+avctx->hwaccel_context = vtctx ?: 
av_videotoolbox_alloc_context_with_pix_fmt(pix_fmt, full_range);
 if (!avctx->hwaccel_context)
 return AVERROR(ENOMEM);
 return videotoolbox_start(avctx);
diff --git a/libavutil/hwcontext_videotoolbox.c 
b/libavutil/hwcontext_videotoolbox.c
index 6eac2c0774..bded9873fe 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -34,16 +34,19 @@

 static const struct {
 uint32_t cv_fmt;
+bool full_range;
 enum AVPixelFormat pix_fmt;
 } cv_pix_fmts[] = {
-{ kCVPixelFormatType_420YpCbCr8Planar,  AV_PIX_FMT_YUV420P },
-{ kCVPixelFormatType_422YpCbCr8,AV_PIX_FMT_UYVY422 },
-{ kCVPixelFormatType_32BGRA,AV_PIX_FMT_BGRA },
+{ kCVPixelFormatType_420YpCbCr8Planar,  false, 
AV_PIX_FMT_YUV420P },
+{ kCVPixelFormatType_422YpCbCr8,false, 
AV_PIX_FMT_UYVY422 },
+{ kCVPixelFormatType_32BGRA,false, AV_PIX_FMT_BGRA 
},
 #ifdef kCFCoreFoundationVersionNumber10_7
-{ kCVPixelFormatType_420YpCbCr8BiPlanarVideoRange,  AV_PIX_FMT_NV12 },

Re: [FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

2019-04-13 Thread Paul B Mahol
Hi,

On 4/13/19, Eugene Lyapustin  wrote:
> Add filter for conversion between various panorama formats.
> Supported formats: equirectangular, cubemap 3x2, cubemap 6x1
>
> Contributions:
>
> unify remap calculation procedure
> add option for interpolation method
>
> Signed-off-by: Eugene Lyapustin 
>
> ---
>
> use bilinear from cubemap to equirectangular
> Change cube faces order to match Youtube's
> avfilter: add convertion to/from cubemap 6x1
>
> Signed-off-by: Hazem Ashmawy 
>
> ---
>
> avfilter: add panorama filter
>
> Signed-off-by: Paul B Mahol 
>
> Signed-off-by: Eugene Lyapustin 

Looks OK, some idea to implement later:
 -Reordering of cube faces by option which sets them in order.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec: add LSCR decoder

2019-04-13 Thread Paul B Mahol
On 4/12/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +++
>  libavcodec/pngdec.c | 135 
>  libavformat/riff.c  |   1 +
>  6 files changed, 146 insertions(+)
>

Will push improved patch soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

2019-04-13 Thread Moritz Barsnick
On Sat, Apr 13, 2019 at 15:50:14 +0300, Eugene Lyapustin wrote:
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_panorama.c | 637 ++

The documentation in doc/filters.texi also needs to be amended.

> +static const AVOption panorama_options[] = {
> +{"input", "set input projection", OFFSET(in), 
> AV_OPT_TYPE_INT,   {.i64=EQUIRECTANGULAR}, 0,NB_PROJECTIONS-1, FLAGS, 
> "in" },
> +{"e", "equirectangular",   0, 
> AV_OPT_TYPE_CONST, {.i64=EQUIRECTANGULAR}, 0,   0, FLAGS, 
> "in" },
> +{ "c6x1", "cubemap",   0, 
> AV_OPT_TYPE_CONST, {.i64=CUBEMAP_6_1}, 0,   0, FLAGS, 
> "in" },
> +{ "c3x2", "cubemap",   0, 
> AV_OPT_TYPE_CONST, {.i64=CUBEMAP_3_2}, 0,   0, FLAGS, 
> "in" },

These two options should get differing descriptions.
(BTW, though others may hate it, I find this formatting very well
readable!)

> +static inline int equal(double a, double b, double epsilon)
> +{
> +return fabs(a - b) < epsilon;
> +}
> +
> +static inline int smaller(double a, double b, double epsilon)
> +{
> +return ((a - b) < 0.0) && (!equal(a, b, epsilon));
> +}

If something comparable doesn't already exist, these could become
macros similar to FF_MAX/MIX et.al.

> +if (face == BACK) {
[...]
> +} else if (face == LEFT) {
[...]
> +} else if (face == FRONT) {
[...]

What about switch/case? Just wondering.

> +} else {
> +;
> +}

I'm not sure an empty else should be expressed. ;-)

(Both previous comments are valid for various sections in the code.)

I don't understand most of the code, so no further comments from me.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/truemotion2: Fix integer overflow in tm2_decode_blocks()

2019-04-13 Thread Michael Niedermayer
On Wed, Mar 27, 2019 at 01:17:41AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 255 + 2147483634 cannot be represented in 
> type 'int'
> Fixes: 
> 13472/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TRUEMOTION2_fuzzer-5712444142387200
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/truemotion2.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi: add colorkey_opencl filter

2019-04-13 Thread Mark Thompson
On 11/04/2019 03:42, Cld fire wrote:
> On Wed, Apr 10, 2019 at 6:10 PM Mark Thompson  wrote:
>>> +// Make sure the input is a format we support
>>> +if (fmt != AV_PIX_FMT_ARGB &&
>>> +fmt != AV_PIX_FMT_RGBA &&
>>> +fmt != AV_PIX_FMT_ABGR &&
>>> +fmt != AV_PIX_FMT_BGRA &&
>>> +fmt != AV_PIX_FMT_NONE
>>
>> Why NONE here?
>>
> 
> It was in the list of formats that the CPU filter said it supported and,
> after briefly looking around, it appeared
> that it was used as a generic special case of some kind (?). There's no
> documentation on the enum variant,
> though, so wasn't able to figure out its exact meaning. Judging by your
> question, perhaps it is irrelevant for
> HW frames?

You mean the list at 
?
  AV_PIX_FMT_NONE (-1) is the invalid enum AVPixelFormat value used as the 
sentinel for the end of the list passed to ff_make_format_list().

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavfi: add nlmeans_opencl filter

2019-04-13 Thread Mark Thompson
On 12/04/2019 08:38, Song, Ruiling wrote:
 +#define RELEASE_KERNEL(k)\
 +do { \
 +if (k) { \
 +cle = clReleaseKernel(k);\
 +if (cle != CL_SUCCESS)   \
 +av_log(avctx, AV_LOG_ERROR, "Failed to release " \
 +   "kernel: %d.\n", cle);\
 +}\
 +} while(0)
>>>
>>> This appears multiple times here and also in other filters.  Maybe it 
>>> should be a
>>> macro in opencl.h like CL_SET_KERNEL_ARG?
> Hi Mark,
> 
> I am rethinking about this problem, can we just simply call clReleaseKernel() 
> and not checking the input and the error_code.
> OpenCL spec has require implementation to check the input argument. So I 
> think we can just ignore the if-null check.

I'm not sure that's true?  The spec allows a CL_INVALID_KERNEL error, but 
doesn't offer any clear indication of when it should be returned (NULL is 
distinguished in other cases, but not here).  Random pointers certainly do 
crash implementations, so they aren't interpreting it as a requirement to 
validate the pointer generally (against some list in the context, say).

The standard ICD loader does have a null check returning CL_INVALID_KERNEL, but 
there is no requirement that it is used rather than linking to a particular ICD 
directly.

> As we are destroying the objects, is it still useful to care the error code 
> returned?

Probably not, I agree.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cbs_av1: add support for Padding OBUs

2019-04-13 Thread James Almer
On 4/13/2019 4:21 PM, James Almer wrote:
> Based on itut_t35 Matadata OBU parsing code.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs_av1.c | 20 +
>  libavcodec/cbs_av1.h |  7 ++
>  libavcodec/cbs_av1_syntax_template.c | 32 
>  3 files changed, 59 insertions(+)

Ignore this one. Sent the same version by mistake.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2 v2] avcodec/cbs_av1: add support for Padding OBUs

2019-04-13 Thread James Almer
Based on itut_t35 Matadata OBU parsing code.

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 20 
 libavcodec/cbs_av1.h |  7 +++
 libavcodec/cbs_av1_syntax_template.c | 24 
 3 files changed, 51 insertions(+)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 0c03ca28af..c175038f0d 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -868,6 +868,11 @@ static void cbs_av1_free_tile_data(AV1RawTileData *td)
 av_buffer_unref(&td->data_ref);
 }
 
+static void cbs_av1_free_padding(AV1RawPadding *pd)
+{
+av_buffer_unref(&pd->payload_ref);
+}
+
 static void cbs_av1_free_metadata(AV1RawMetadata *md)
 {
 switch (md->metadata_type) {
@@ -894,6 +899,9 @@ static void cbs_av1_free_obu(void *unit, uint8_t *content)
 case AV1_OBU_METADATA:
 cbs_av1_free_metadata(&obu->obu.metadata);
 break;
+case AV1_OBU_PADDING:
+cbs_av1_free_padding(&obu->obu.padding);
+break;
 }
 
 av_freep(&obu);
@@ -1068,6 +1076,12 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_read_padding(ctx, &gbc, &obu->obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
@@ -1193,6 +1207,12 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_write_padding(ctx, pbc, &obu->obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 71ceff9427..e799964b72 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -364,6 +364,12 @@ typedef struct AV1RawMetadata {
 } metadata;
 } AV1RawMetadata;
 
+typedef struct AV1RawPadding {
+uint8_t *payload;
+size_t   payload_size;
+AVBufferRef *payload_ref;
+} AV1RawPadding;
+
 
 typedef struct AV1RawOBU {
 AV1RawOBUHeader header;
@@ -377,6 +383,7 @@ typedef struct AV1RawOBU {
 AV1RawTileGroup  tile_group;
 AV1RawTileList   tile_list;
 AV1RawMetadata   metadata;
+AV1RawPaddingpadding;
 } obu;
 } AV1RawOBU;
 
diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 56009145e8..675bfe5bb4 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1755,3 +1755,27 @@ static int FUNC(metadata_obu)(CodedBitstreamContext 
*ctx, RWContext *rw,
 
 return 0;
 }
+
+static int FUNC(padding)(CodedBitstreamContext *ctx, RWContext *rw,
+ AV1RawPadding *current)
+{
+int i, err;
+
+HEADER("Padding");
+
+#ifdef READ
+// The payload runs up to the start of the trailing bits, but there might
+// be arbitrarily many trailing zeroes so we need to read through twice.
+current->payload_size = cbs_av1_get_payload_bytes_left(rw);
+
+current->payload_ref = av_buffer_alloc(current->payload_size);
+if (!current->payload_ref)
+return AVERROR(ENOMEM);
+current->payload = current->payload_ref->data;
+#endif
+
+for (i = 0; i < current->payload_size; i++)
+xf(8, obu_padding_byte[i], current->payload[i], 0x00, 0xff, 1, i);
+
+return 0;
+}
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avcodec/cbs_av1: add support for Padding OBUs

2019-04-13 Thread James Almer
Based on itut_t35 Matadata OBU parsing code.

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 20 +
 libavcodec/cbs_av1.h |  7 ++
 libavcodec/cbs_av1_syntax_template.c | 32 
 3 files changed, 59 insertions(+)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 02f168b58d..22330eabf3 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -857,6 +857,11 @@ static void cbs_av1_free_tile_data(AV1RawTileData *td)
 av_buffer_unref(&td->data_ref);
 }
 
+static void cbs_av1_free_padding(AV1RawPadding *pd)
+{
+av_buffer_unref(&pd->payload_ref);
+}
+
 static void cbs_av1_free_metadata(AV1RawMetadata *md)
 {
 switch (md->metadata_type) {
@@ -883,6 +888,9 @@ static void cbs_av1_free_obu(void *unit, uint8_t *content)
 case AV1_OBU_METADATA:
 cbs_av1_free_metadata(&obu->obu.metadata);
 break;
+case AV1_OBU_PADDING:
+cbs_av1_free_padding(&obu->obu.padding);
+break;
 }
 
 av_freep(&obu);
@@ -1057,6 +1065,12 @@ static int cbs_av1_read_unit(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_read_padding(ctx, &gbc, &obu->obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
@@ -1182,6 +1196,12 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 }
 break;
 case AV1_OBU_PADDING:
+{
+err = cbs_av1_write_padding(ctx, pbc, &obu->obu.padding);
+if (err < 0)
+return err;
+}
+break;
 default:
 return AVERROR(ENOSYS);
 }
diff --git a/libavcodec/cbs_av1.h b/libavcodec/cbs_av1.h
index 71ceff9427..e799964b72 100644
--- a/libavcodec/cbs_av1.h
+++ b/libavcodec/cbs_av1.h
@@ -364,6 +364,12 @@ typedef struct AV1RawMetadata {
 } metadata;
 } AV1RawMetadata;
 
+typedef struct AV1RawPadding {
+uint8_t *payload;
+size_t   payload_size;
+AVBufferRef *payload_ref;
+} AV1RawPadding;
+
 
 typedef struct AV1RawOBU {
 AV1RawOBUHeader header;
@@ -377,6 +383,7 @@ typedef struct AV1RawOBU {
 AV1RawTileGroup  tile_group;
 AV1RawTileList   tile_list;
 AV1RawMetadata   metadata;
+AV1RawPaddingpadding;
 } obu;
 } AV1RawOBU;
 
diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 76eb90b279..a6cafdd99f 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1763,3 +1763,35 @@ static int FUNC(metadata_obu)(CodedBitstreamContext 
*ctx, RWContext *rw,
 
 return 0;
 }
+
+static int FUNC(padding)(CodedBitstreamContext *ctx, RWContext *rw,
+ AV1RawPadding *current)
+{
+int i, err;
+
+HEADER("Padding");
+
+#ifdef READ
+// The payload runs up to the start of the trailing bits, but there might
+// be arbitrarily many trailing zeroes so we need to read through twice.
+{
+GetBitContext tmp = *rw;
+current->payload_size = 0;
+for (i = 0; get_bits_left(rw) >= 8; i++) {
+if (get_bits(rw, 8))
+current->payload_size = i;
+}
+*rw = tmp;
+
+current->payload_ref = av_buffer_alloc(current->payload_size);
+if (!current->payload_ref)
+return AVERROR(ENOMEM);
+current->payload = current->payload_ref->data;
+}
+#endif
+
+for (i = 0; i < current->payload_size; i++)
+xf(8, obu_padding_byte[i], current->payload[i], 0x00, 0xff, 1, i);
+
+return 0;
+}
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/cbs_av1: add a function to get a payload size without trailing zero bytes

2019-04-13 Thread James Almer
Factor it out from cbs_av1_read_metadata_itut_t35()

Signed-off-by: James Almer 
---
 libavcodec/cbs_av1.c | 11 +++
 libavcodec/cbs_av1_syntax_template.c | 10 +-
 2 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index f02cca2dad..0c03ca28af 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -574,6 +574,17 @@ static int cbs_av1_get_relative_dist(const 
AV1RawSequenceHeader *seq,
 return diff;
 }
 
+static int cbs_av1_get_payload_bytes_left(GetBitContext *gbc)
+{
+GetBitContext tmp = *gbc;
+int size = 0;
+for (int i = 0; get_bits_left(&tmp) >= 8; i++) {
+if (get_bits(&tmp, 8))
+size = i;
+}
+return size;
+}
+
 
 #define HEADER(name) do { \
 ff_cbs_trace_header(ctx, name); \
diff --git a/libavcodec/cbs_av1_syntax_template.c 
b/libavcodec/cbs_av1_syntax_template.c
index 76eb90b279..56009145e8 100644
--- a/libavcodec/cbs_av1_syntax_template.c
+++ b/libavcodec/cbs_av1_syntax_template.c
@@ -1674,15 +1674,7 @@ static int FUNC(metadata_itut_t35)(CodedBitstreamContext 
*ctx, RWContext *rw,
 #ifdef READ
 // The payload runs up to the start of the trailing bits, but there might
 // be arbitrarily many trailing zeroes so we need to read through twice.
-{
-GetBitContext tmp = *rw;
-current->payload_size = 0;
-for (i = 0; get_bits_left(rw) >= 8; i++) {
-if (get_bits(rw, 8))
-current->payload_size = i;
-}
-*rw = tmp;
-}
+current->payload_size = cbs_av1_get_payload_bytes_left(rw);
 
 current->payload_ref = av_buffer_alloc(current->payload_size);
 if (!current->payload_ref)
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [GSOC] [PATCH] avfilter: add panorama filter

2019-04-13 Thread Eugene Lyapustin

On 13.04.2019 19:30, Moritz Barsnick wrote:


On Sat, Apr 13, 2019 at 15:50:14 +0300, Eugene Lyapustin wrote:

+static inline int equal(double a, double b, double epsilon)
+{
+return fabs(a - b) < epsilon;
+}
+
+static inline int smaller(double a, double b, double epsilon)
+{
+return ((a - b) < 0.0) && (!equal(a, b, epsilon));
+}

If something comparable doesn't already exist, these could become
macros similar to FF_MAX/MIX et.al.


These functions are local, so that change should not make much 
difference. Correct me if I'm wrong :)


Thanks for comments,
Eugene Lyapustin

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [GSOC] [PATCH v2] avfilter: add panorama filter

2019-04-13 Thread Eugene Lyapustin
Add filter for conversion between various panorama formats.
Supported formats: equirectangular, cubemap 3x2, cubemap 6x1

Contributions:

doc/filters: add panorama filter description
unify remap calculation procedure
add option for interpolation method

Signed-off-by: Eugene Lyapustin 

---

use bilinear from cubemap to equirectangular
Change cube faces order to match Youtube's
avfilter: add convertion to/from cubemap 6x1

Signed-off-by: Hazem Ashmawy 

---

avfilter: add panorama filter

Signed-off-by: Paul B Mahol 

Signed-off-by: Eugene Lyapustin 
---
 doc/filters.texi  |  50 +++
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_panorama.c | 647 ++
 4 files changed, 699 insertions(+)
 create mode 100644 libavfilter/vf_panorama.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 867607d870..2e9bf81e12 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13382,6 +13382,56 @@ ffmpeg -i input.mkv -i palette.png -lavfi paletteuse 
output.gif
 @end example
 @end itemize
 
+@section panorama
+
+Convert panorama videos between various formats.
+
+The filter accepts the following options:
+
+@table @option
+@item input
+Set format of input video.
+@item output
+Set format of output video.
+
+Available formats:
+
+@table @samp
+@item e
+Equirectangular projection.
+@item c6x1
+Cubemap with 6x1 layout.
+@item c3x2
+Cubemap with 3x2 layout.
+
+@end table
+
+@item interp
+Set interpolation method.
+
+Available methods:
+
+@table @samp
+@item near
+Nearest neighbour
+@item line
+Bilinear interpolation
+@end table
+
+Default value is @samp{line}.
+
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Convert equirectangular video to cubemap with 3x2 layout using bilinear 
interpolation:
+@example
+ffmpeg -i input.mkv -vf panorama=e:c3x2:line output.mkv
+@end example
+@end itemize
+
 @section perspective
 
 Correct perspective of video not recorded perpendicular to the screen.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..3c272da7b2 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -307,6 +307,7 @@ OBJS-$(CONFIG_OWDENOISE_FILTER)  += 
vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
 OBJS-$(CONFIG_PALETTEGEN_FILTER) += vf_palettegen.o
 OBJS-$(CONFIG_PALETTEUSE_FILTER) += vf_paletteuse.o framesync.o
+OBJS-$(CONFIG_PANORAMA_FILTER)   += vf_panorama.o
 OBJS-$(CONFIG_PERMS_FILTER)  += f_perms.o
 OBJS-$(CONFIG_PERSPECTIVE_FILTER)+= vf_perspective.o
 OBJS-$(CONFIG_PHASE_FILTER)  += vf_phase.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..f49c0a40e0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -292,6 +292,7 @@ extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
 extern AVFilter ff_vf_palettegen;
 extern AVFilter ff_vf_paletteuse;
+extern AVFilter ff_vf_panorama;
 extern AVFilter ff_vf_perms;
 extern AVFilter ff_vf_perspective;
 extern AVFilter ff_vf_phase;
diff --git a/libavfilter/vf_panorama.c b/libavfilter/vf_panorama.c
new file mode 100644
index 00..8fa0310349
--- /dev/null
+++ b/libavfilter/vf_panorama.c
@@ -0,0 +1,647 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/eval.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "video.h"
+
+enum Projections {
+EQUIRECTANGULAR,
+CUBEMAP_6_1,
+CUBEMAP_3_2,
+NB_PROJECTIONS,
+};
+
+enum InterpMethod {
+  NEAREST,
+  BILINEAR,
+  NB_INTERP_METHODS,
+};
+
+enum Faces {
+RIGHT,
+LEFT,
+TOP,
+DOWN,
+FRONT,
+BACK,
+};
+
+struct XYRemap {
+int vi, ui;
+int v2, u2;
+double a, b, c, d;
+};
+
+typedef struct PanoramaContext {
+const AVClass *class;
+int in, out;
+int interp;
+
+int planewidth[4], planeheight[4];
+int inplanewidth[4], inplaneheight[4];
+int nb_planes;
+
+struct XYRemap *remap[4];
+
+int (*panorama)(struct PanoramaContext *s

[FFmpeg-devel] [PATCH]lavfi/fspp: Add a cast to silence a clang warning

2019-04-13 Thread Carl Eugen Hoyos
Hi!

Attached patch silences two warnings shown when compiling with clang:
libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int'
to 'int16_t' (aka 'short') changes value from 44130 to -21406

Please comment, Carl Eugen
From d731e523d9c5854183d20d37fe921f49fb048498 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 13 Apr 2019 23:05:44 +0200
Subject: [PATCH] lavfi/fspp: Add two casts to int16_t.

Silences a warning with clang:
warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes value from 44130 to -21406
---
 libavfilter/vf_fspp.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
index 74a3447..e346439 100644
--- a/libavfilter/vf_fspp.h
+++ b/libavfilter/vf_fspp.h
@@ -31,7 +31,7 @@
 #define DCTSIZE 8
 #define DCTSIZE_S "8"
 
-#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
+#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5) & (int16_t)0x)
 #define C64(x)((uint64_t)((x) | (x) << 16)) <<32 | (uint64_t)(x) | (uint64_t)(x) << 16
 #define FIX64(x,s)  C64(FIX(x,s))
 
-- 
1.7.10.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavfi/fspp: Add a cast to silence a clang warning

2019-04-13 Thread James Almer
On 4/13/2019 7:04 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch silences two warnings shown when compiling with clang:
> libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int'
> to 'int16_t' (aka 'short') changes value from 44130 to -21406
> 
> Please comment, Carl Eugen
> 
> 
> 0001-lavfi-vf_fspp-Use-the-intended-cast-to-int16_t.patch
> 
> From d731e523d9c5854183d20d37fe921f49fb048498 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Sat, 13 Apr 2019 23:05:44 +0200
> Subject: [PATCH] lavfi/fspp: Add two casts to int16_t.
> 
> Silences a warning with clang:
> warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes 
> value from 44130 to -21406
> ---
>  libavfilter/vf_fspp.h |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
> index 74a3447..e346439 100644
> --- a/libavfilter/vf_fspp.h
> +++ b/libavfilter/vf_fspp.h
> @@ -31,7 +31,7 @@
>  #define DCTSIZE 8
>  #define DCTSIZE_S "8"
>  
> -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
> +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5) & (int16_t)0x)

The "& 0x" is turning -21406 into 44130 since it zeroes all the high
bits, and then that value gets converted back to -21406 when stored into
an int16_t variable.

Change the int cast into int16_t if you want since it doesn't hurt (all
the values are safely within the int16_t range anyway), but remove the
"& 0x" altogether instead of casting it, to get rid of this warning.

>  #define C64(x)((uint64_t)((x) | (x) << 16)) <<32 | (uint64_t)(x) | 
> (uint64_t)(x) << 16
>  #define FIX64(x,s)  C64(FIX(x,s))
>  
> -- 1.7.10.4
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-13 Thread Marton Balint


On Sat, 6 Apr 2019, Balint Marton wrote:


Hi All

Here is a call for the people in the voting committee [1] on the decision 
of extending it.



[...]


Some of these developers are already in the voting committee, the new ones 
would be:


Aman Gupta
Gyan Doshi
Jan Ekström
Jun Zhao
Karthick Jeyapal
Mark Thompson
Martin Vignali
Peter Ross
Steven Liu
Timo Rothenpieler
Zhong Li

Question: Do you support extending the voting committte with the people 
above?


I suggest a deadline for making a decision on these 11 people of 7 days
starting now.


Thanks for everyone who voted, I counted 5 votes supporting this, 0 
against.


So from now on, the voting committe consists of these people:

Aman Gupta
Andreas Cadhalpun
Carl Eugen Hoyos
Christophe Gisquet
Clément Bœsch
Ganesh Ajjanagadde
Gyan Doshi
Hendrik Leppkes
James Almer
Jan Ekström
Jun Zhao
Karthick Jeyapal
Lou Logan
Lukasz Marek
Mark Thompson
Martin Vignali
Marton Balint
Michael Niedermayer
Nicolas George
Paul B Mahol
Peter Ross
Philip Langdale
Reimar Döffinger
Reynaldo H. Verdejo Pinochet
Rodger Combs
Ronald S. Bultje
Rostislav Pehlivanov
Stefano Sabatini
Steven Liu
Timo Rothenpieler
Timothy Gu
wm4
Zhong Li

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH]lavfi/fspp: Add a cast to silence a clang warning

2019-04-13 Thread Michael Niedermayer
On Sat, Apr 13, 2019 at 07:25:54PM -0300, James Almer wrote:
> On 4/13/2019 7:04 PM, Carl Eugen Hoyos wrote:
> > Hi!
> > 
> > Attached patch silences two warnings shown when compiling with clang:
> > libavfilter/vf_fspp.h:51:42: warning: implicit conversion from 'int'
> > to 'int16_t' (aka 'short') changes value from 44130 to -21406
> > 
> > Please comment, Carl Eugen
> > 
> > 
> > 0001-lavfi-vf_fspp-Use-the-intended-cast-to-int16_t.patch
> > 
> > From d731e523d9c5854183d20d37fe921f49fb048498 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos 
> > Date: Sat, 13 Apr 2019 23:05:44 +0200
> > Subject: [PATCH] lavfi/fspp: Add two casts to int16_t.
> > 
> > Silences a warning with clang:
> > warning: implicit conversion from 'int' to 'int16_t' (aka 'short') changes 
> > value from 44130 to -21406
> > ---
> >  libavfilter/vf_fspp.h |2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavfilter/vf_fspp.h b/libavfilter/vf_fspp.h
> > index 74a3447..e346439 100644
> > --- a/libavfilter/vf_fspp.h
> > +++ b/libavfilter/vf_fspp.h
> > @@ -31,7 +31,7 @@
> >  #define DCTSIZE 8
> >  #define DCTSIZE_S "8"
> >  
> > -#define FIX(x,s)  ((int) ((x) * (1 << s) + 0.5) & 0x)
> > +#define FIX(x,s)  ((int16_t)((x) * (1 << s) + 0.5) & (int16_t)0x)
> 
> The "& 0x" is turning -21406 into 44130 since it zeroes all the high
> bits, and then that value gets converted back to -21406 when stored into
> an int16_t variable.
> 
> Change the int cast into int16_t if you want since it doesn't hurt (all
> the values are safely within the int16_t range anyway), but remove the
> "& 0x" altogether instead of casting it, to get rid of this warning.
> 
> >  #define C64(x)((uint64_t)((x) | (x) << 16)) <<32 | (uint64_t)(x) | 
> > (uint64_t)(x) << 16
> >  #define FIX64(x,s)  C64(FIX(x,s))

i think the C64 / FIX64 macros depend on the & 0x. They are maybe unused
and just referenced in comments but having them not give correct values
could still be confusing. The 0x if its removed should be added to the
code / comments that refer to it in a way that needs it

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V1] avformat/avformat.h: correct the comment for AVInputFormat.extensions

2019-04-13 Thread Michael Niedermayer
On Sat, Apr 13, 2019 at 08:46:06AM +0800, Jun Zhao wrote:
> From: Jun Zhao 
> 
> Now the probe logic is: Only read_probe is NULL and extensions are defined,
> then no probe is done. Correct the comment to follow the coding logic.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavformat/avformat.h |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 734ae54..bbfa61d 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -659,8 +659,8 @@ typedef struct AVInputFormat {
>  int flags;
>  
>  /**
> - * If extensions are defined, then no probe is done. You should
> - * usually not use extension format guessing because it is not

> + * If read_probe is NULL and extensions are defined, then no probe is 
> done.

Why do you refer to extensions here ?
if read_probe is not set (NULL), no probe (based on input content) can be done,
extensions does not change that.

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

There will always be a question for which you do not know the correct answer.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-13 Thread James Almer
On 4/13/2019 7:47 PM, Marton Balint wrote:
> 
> On Sat, 6 Apr 2019, Balint Marton wrote:
> 
>> Hi All
>>
>> Here is a call for the people in the voting committee [1] on the
>> decision of extending it.
>>
> [...]
>>
>> Some of these developers are already in the voting committee, the new
>> ones would be:
>>
>> Aman Gupta
>> Gyan Doshi
>> Jan Ekström
>> Jun Zhao
>> Karthick Jeyapal
>> Mark Thompson
>> Martin Vignali
>> Peter Ross
>> Steven Liu
>> Timo Rothenpieler
>> Zhong Li
>>
>> Question: Do you support extending the voting committte with the
>> people above?
>>
>> I suggest a deadline for making a decision on these 11 people of 7 days
>> starting now.
> 
> Thanks for everyone who voted, I counted 5 votes supporting this, 0
> against.
> 
> So from now on, the voting committe consists of these people:
> 
> Aman Gupta
> Andreas Cadhalpun

Andreas hasn't been around for a long time.

> Carl Eugen Hoyos
> Christophe Gisquet
> Clément Bœsch
> Ganesh Ajjanagadde

Same with Ganesh.

> Gyan Doshi
> Hendrik Leppkes
> James Almer
> Jan Ekström
> Jun Zhao
> Karthick Jeyapal
> Lou Logan
> Lukasz Marek
> Mark Thompson
> Martin Vignali

Martin recently called it quits, removing himself from Maintainers,
after the recent NDI debacle.

> Marton Balint
> Michael Niedermayer
> Nicolas George
> Paul B Mahol
> Peter Ross
> Philip Langdale
> Reimar Döffinger
> Reynaldo H. Verdejo Pinochet
> Rodger Combs
> Ronald S. Bultje
> Rostislav Pehlivanov
> Stefano Sabatini
> Steven Liu
> Timo Rothenpieler
> Timothy Gu
> wm4

And I'm fairly sure wm4 did as well.

> Zhong Li
> 
> Regards,
> Marton

This list is getting long and starting to have people no longer
participating or contributing to the project. It might be worth looking
into culling it in some form.

And IMO, commit count shouldn't be the only thing that counts when
ML/IRC presence, contributed work, review activity, etc, are also important.
Plenty of people in this list haven't committed much in a while, but
still review and participate on both the ml and IRC.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [DECISION] Include more developers in the voting committee [#4]

2019-04-13 Thread Marton Balint



On Sat, 13 Apr 2019, James Almer wrote:


On 4/13/2019 7:47 PM, Marton Balint wrote:


On Sat, 6 Apr 2019, Balint Marton wrote:


Hi All

Here is a call for the people in the voting committee [1] on the
decision of extending it.


[...]


Some of these developers are already in the voting committee, the new
ones would be:

Aman Gupta
Gyan Doshi
Jan Ekström
Jun Zhao
Karthick Jeyapal
Mark Thompson
Martin Vignali
Peter Ross
Steven Liu
Timo Rothenpieler
Zhong Li

Question: Do you support extending the voting committte with the
people above?

I suggest a deadline for making a decision on these 11 people of 7 days
starting now.


Thanks for everyone who voted, I counted 5 votes supporting this, 0
against.

So from now on, the voting committe consists of these people:

Aman Gupta
Andreas Cadhalpun


Andreas hasn't been around for a long time.


Carl Eugen Hoyos
Christophe Gisquet
Clément Bœsch
Ganesh Ajjanagadde


Same with Ganesh.


Gyan Doshi
Hendrik Leppkes
James Almer
Jan Ekström
Jun Zhao
Karthick Jeyapal
Lou Logan
Lukasz Marek
Mark Thompson
Martin Vignali


Martin recently called it quits, removing himself from Maintainers,
after the recent NDI debacle.


Marton Balint
Michael Niedermayer
Nicolas George
Paul B Mahol
Peter Ross
Philip Langdale
Reimar Döffinger
Reynaldo H. Verdejo Pinochet
Rodger Combs
Ronald S. Bultje
Rostislav Pehlivanov
Stefano Sabatini
Steven Liu
Timo Rothenpieler
Timothy Gu
wm4


And I'm fairly sure wm4 did as well.


Zhong Li

Regards,
Marton


This list is getting long and starting to have people no longer
participating or contributing to the project. It might be worth looking
into culling it in some form.


Sure, although it is not a big issue if inactive people are on the list, 
votes are generally simple majority votes, and active people are voting 
anyways.



And IMO, commit count shouldn't be the only thing that counts when
ML/IRC presence, contributed work, review activity, etc, are also important.
Plenty of people in this list haven't committed much in a while, but
still review and participate on both the ml and IRC.


Commit count is only a guideline. A vote puts people in the committee, in 
theory anybody can propose anyone. If you feel someone is left out, please 
start another vote.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] lavfi: add colorkey_opencl filter

2019-04-13 Thread Jarek Samic
This is a direct port of the CPU filter.

Signed-off-by: Jarek Samic 
---
I've made the changes requested from the first patch. I also investigated 
splitting the kernel into two kernels in order to remove the blending if 
branch; I noticed negligible performance improvement (if any at all) with my 
test case and hardware, but I've left it split up as it's possible that it 
makes a difference with different hardware (and it's very little change in the 
code).

 configure|   1 +
 doc/filters.texi |  33 +
 libavfilter/Makefile |   2 +
 libavfilter/allfilters.c |   1 +
 libavfilter/opencl/colorkey.cl   |  53 +++
 libavfilter/opencl_source.h  |   1 +
 libavfilter/vf_colorkey_opencl.c | 243 +++
 7 files changed, 334 insertions(+)
 create mode 100644 libavfilter/opencl/colorkey.cl
 create mode 100644 libavfilter/vf_colorkey_opencl.c

diff --git a/configure b/configure
index c2580b34c3..6515cdc149 100755
--- a/configure
+++ b/configure
@@ -3412,6 +3412,7 @@ boxblur_filter_deps="gpl"
 boxblur_opencl_filter_deps="opencl gpl"
 bs2b_filter_deps="libbs2b"
 colormatrix_filter_deps="gpl"
+colorkey_opencl_filter_deps="opencl"
 convolution_opencl_filter_deps="opencl"
 convolve_filter_deps="avcodec"
 convolve_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 867607d870..390c8b97cf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -19030,6 +19030,39 @@ Apply erosion filter with threshold0 set to 30, 
threshold1 set 40, threshold2 se
 @end example
 @end itemize
 
+@section colorkey_opencl
+RGB colorspace color keying.
+
+The filter accepts the following options:
+
+@table @option
+@item color
+The color which will be replaced with transparency.
+
+@item similarity
+Similarity percentage with the key color.
+
+0.01 matches only the exact key color, while 1.0 matches everything.
+
+@item blend
+Blend percentage.
+
+0.0 makes pixels either fully transparent, or not transparent at all.
+
+Higher values result in semi-transparent pixels, with a higher transparency
+the more similar the pixels color is to the key color.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+Make every semi-green pixel in the input transparent with some slight blending:
+@example
+-i INPUT -vf "hwupload, colorkey_opencl=green:0.3:0.1, hwdownload" OUTPUT
+@end example
+@end itemize
+
 @section overlay_opencl
 
 Overlay one video on top of another.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fef6ec5c55..9589dd8747 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -176,6 +176,8 @@ OBJS-$(CONFIG_CODECVIEW_FILTER)  += 
vf_codecview.o
 OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
 OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER)  += vf_colorchannelmixer.o
 OBJS-$(CONFIG_COLORKEY_FILTER)   += vf_colorkey.o
+OBJS-$(CONFIG_COLORKEY_OPENCL_FILTER)+= vf_colorkey_opencl.o opencl.o \
+opencl/colorkey.o
 OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspace.o 
colorspacedsp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c51ae0f3c7..ff4eb5bf6b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -165,6 +165,7 @@ extern AVFilter ff_vf_codecview;
 extern AVFilter ff_vf_colorbalance;
 extern AVFilter ff_vf_colorchannelmixer;
 extern AVFilter ff_vf_colorkey;
+extern AVFilter ff_vf_colorkey_opencl;
 extern AVFilter ff_vf_colorlevels;
 extern AVFilter ff_vf_colormatrix;
 extern AVFilter ff_vf_colorspace;
diff --git a/libavfilter/opencl/colorkey.cl b/libavfilter/opencl/colorkey.cl
new file mode 100644
index 00..82ab5c8832
--- /dev/null
+++ b/libavfilter/opencl/colorkey.cl
@@ -0,0 +1,53 @@
+/*
+ * 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
+ */
+
+float4 get_pixel(image2d_t src, int2 loc) {
+const sampler_t sampler = CLK_NORMALIZED_COORDS_FALSE |
+CLK_FILTER_NEAREST;
+
+return read_imagef(src, sampler, loc);
+}
+
+__kernel void colorkey_blend(
+__read_only  im

Re: [FFmpeg-devel] [PATCH] lavfi: add colorkey_opencl filter

2019-04-13 Thread Cld fire
>
> You mean the list at <
> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/vf_colorkey.c;h=3d65e59d42c6fa480e00f4b7ab079677bcac876a;hb=HEAD#l113>?
> AV_PIX_FMT_NONE (-1) is the invalid enum AVPixelFormat value used as the
> sentinel for the end of the list passed to ff_make_format_list().
>

Ah, that makes sense.

I've sent in an updated patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".