date:20190128

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

2019-01-28 Thread Marton Balint


From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 28 Jan 2019 12:20:02 +0530
Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
 missing CRLF

---
 libavformat/http.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 240304f6e6..2f2ce856bc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char *uri, int 
flags,
 int len = strlen(s->headers);
 if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
 av_log(h, AV_LOG_WARNING,
-   "No trailing CRLF found in HTTP header.\n");
+   "No trailing CRLF found in HTTP header. Adding it.\n");
 ret = av_reallocp(&s->headers, len + 3);
-if (ret < 0)
+if (ret < 0) {
+av_log(h, AV_LOG_ERROR,
+   "Failed to add trailing CRLF.\n");

In general I am against adding messages for ENOMEM cases.

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

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

2019-01-28 Thread Gyan




On 28-01-2019 01:53 PM, Marton Balint wrote:

From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 28 Jan 2019 12:20:02 +0530
Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
 missing CRLF

---
 libavformat/http.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 240304f6e6..2f2ce856bc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char 
*uri, int flags,

 int len = strlen(s->headers);
 if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
 av_log(h, AV_LOG_WARNING,
-   "No trailing CRLF found in HTTP header.\n");
+   "No trailing CRLF found in HTTP header. Adding 
it.\n");

 ret = av_reallocp(&s->headers, len + 3);
-    if (ret < 0)
+    if (ret < 0) {
+    av_log(h, AV_LOG_ERROR,
+   "Failed to add trailing CRLF.\n");

In general I am against adding messages for ENOMEM cases.


The codepath above is contingent upon malformed user input, and not a 
routine alloc. Log message is extended to inform the user we're 
correcting the header.  So I consider it good practice to report its 
failure, rather than leaving it opaque.


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

[FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

2019-01-28 Thread Muhammad Faiz

Fix inconsistent checksums between gbrap10be and gbrap10le
on fate-filter-pixfmts.

Signed-off-by: Muhammad Faiz 
---
 libswscale/swscale_unscaled.c| 3 +++
 tests/ref/fate/filter-pixfmts-copy   | 2 +-
 tests/ref/fate/filter-pixfmts-crop   | 2 +-
 tests/ref/fate/filter-pixfmts-field  | 2 +-
 tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
 tests/ref/fate/filter-pixfmts-hflip  | 2 +-
 tests/ref/fate/filter-pixfmts-il | 2 +-
 tests/ref/fate/filter-pixfmts-null   | 2 +-
 tests/ref/fate/filter-pixfmts-scale  | 2 +-
 tests/ref/fate/filter-pixfmts-transpose  | 2 +-
 tests/ref/fate/filter-pixfmts-vflip  | 2 +-
 11 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 058f2b94db..734a527e68 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == AV_PIX_FMT_GBRP12BE 
||
  dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == AV_PIX_FMT_GBRP14BE 
||
  dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == AV_PIX_FMT_GBRP16BE 
||
+ dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
AV_PIX_FMT_GBRAP10BE ||
  dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
AV_PIX_FMT_GBRAP12BE ||
  dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
AV_PIX_FMT_GBRAP16BE ))
 c->swscale = Rgb16ToPlanarRgb16Wrapper;
@@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
  srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == AV_PIX_FMT_GBRP10BE 
||
  srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == AV_PIX_FMT_GBRP12BE 
||
  srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == AV_PIX_FMT_GBRP14BE 
||
+ srcFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == 
AV_PIX_FMT_GBRAP10BE ||
  srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
AV_PIX_FMT_GBRAP12BE ||
  srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
AV_PIX_FMT_GBRAP16BE) &&
 (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == AV_PIX_FMT_RGB48BE  
||
@@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
+IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
 IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||
diff --git a/tests/ref/fate/filter-pixfmts-copy 
b/tests/ref/fate/filter-pixfmts-copy
index 2417c577bd..82b8f28c31 100644
--- a/tests/ref/fate/filter-pixfmts-copy
+++ b/tests/ref/fate/filter-pixfmts-copy
@@ -25,7 +25,7 @@ bgra64be(le)b71d75a928aac14cb768403e6f6a9910
 bgra64leb71d75a928aac14cb768403e6f6a9910
 gbrap   98d30987407c51e5620921e11d40a4ff
 gbrap10be   edcffb185e44b6dae5c2ead5505b7125
-gbrap10be(le)   3a046be0d38289dda5d8fdbd0f34aaf5
+gbrap10be(le)   2a7392e14b21b1f9457526a071236a6d
 gbrap10le   2a7392e14b21b1f9457526a071236a6d
 gbrap12be   0c4c1f8af361571265ca259d5f70f026
 gbrap12be(le)   5f1d8c663d4c28863e687192433b34a4
diff --git a/tests/ref/fate/filter-pixfmts-crop 
b/tests/ref/fate/filter-pixfmts-crop
index a0e1d9584f..cc32f2c99c 100644
--- a/tests/ref/fate/filter-pixfmts-crop
+++ b/tests/ref/fate/filter-pixfmts-crop
@@ -25,7 +25,7 @@ bgra64be(le)dd29ec9aba43aa3e8f9f5b9a93ca8831
 bgra64ledd29ec9aba43aa3e8f9f5b9a93ca8831
 gbrap   188cd467fe7ae7d85ae9ca8bdfa07739
 gbrap10be   1880c4856d9cc6492b8b859f2711aaf1
-gbrap10be(le)   c8505df07f9eeb413f943b5f4d686c0b
+gbrap10be(le)   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap10le   c2b6e35f8b7ca363a7ec021ccdf31d1f
 gbrap12be   c9769d18733cdc2664d8b9af09a03f6d
 gbrap12be(le)   3f80453c1ac6c5d1b2febf3ef141b476
diff --git a/tests/ref/fate/filter-pixfmts-field 
b/tests/ref/fate/filter-pixfmts-field
index 210fa97e48..3ae7144e26 100644
--- a/tests/ref/fate/filter-pixfmts-field
+++ b/tests/ref/fate/filter-pixfmts-field
@@ -25,7 +25,7 @@ bgra64be(le)9e2def541e51bc6e77fbffbff7fa146a
 bgra64le9e2def541e51bc6e77fbffbff7fa146a
 gbrap   08a28b79dbd19246d1a94e3466af3624
 gbrap10be   29d46cbf021b233f5f1886e5d5fe21b4
-gbrap10be(le)   a5cfc53fbd96fcdf83b8b655fe25bf67
+gbrap10be(le)   4017c5d8c124438eb9aefa107db58d3b
 gbrap10le   4017c5d8c124438eb9aefa107db58d3b
 gbrap12be   e7f471132628b1c034199cc109b84bc2
 gbrap12be(le)   886207e5aa379a0312485b94e5fd5edd
diff --git a/tests/ref/fate/filter-pixfmts-fieldorder 
b/tests/ref/fate/filter-pixfmts-fieldorder
index 8

[FFmpeg-devel] [PATCH v2 5/5] avfilter/drawutils: support native-endian instead of little-endian

2019-01-28 Thread Muhammad Faiz

This should make code run faster on big-endian platform.
Change fate to use native-endian mode.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/drawutils.c   |  36 +++--
 libavfilter/vf_rotate.c   |  26 ++--
 libavfilter/vf_tinterlace.c   |  30 ++--
 tests/fate/filter-video.mak   |  12 +-
 tests/ref/fate/filter-pixfmts-pad | 129 --
 tests/ref/fate/filter-pixfmts-rotate  |  42 --
 .../ref/fate/filter-pixfmts-tinterlace_cvlpf  |  33 +++--
 .../ref/fate/filter-pixfmts-tinterlace_merge  |  33 +++--
 tests/ref/fate/filter-pixfmts-tinterlace_pad  |  33 +++--
 tests/ref/fate/filter-pixfmts-tinterlace_vlpf |  33 +++--
 10 files changed, 251 insertions(+), 156 deletions(-)

diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 5f4cb548f0..7a8ace2c74 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -185,7 +185,7 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 
 if (!desc || !desc->name)
 return AVERROR(EINVAL);
-if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA))
+if (desc->flags & ~(AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_RGB | 
FF_PSEUDOPAL | AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BE))
 return AVERROR(ENOSYS);
 if (format == AV_PIX_FMT_P010LE || format == AV_PIX_FMT_P010BE || format 
== AV_PIX_FMT_P016LE || format == AV_PIX_FMT_P016BE)
 return AVERROR(ENOSYS);
@@ -197,7 +197,8 @@ int ff_draw_init(FFDrawContext *draw, enum AVPixelFormat 
format, unsigned flags)
 /* for now, only 8-16 bits formats */
 if (c->depth < 8 || c->depth > 16)
 return AVERROR(ENOSYS);
-if (desc->flags & AV_PIX_FMT_FLAG_BE)
+/* native-endian only */
+if (c->depth + c->shift > 8 && !(desc->flags & AV_PIX_FMT_FLAG_BE) == 
HAVE_BIGENDIAN)
 return AVERROR(ENOSYS);
 if (c->plane >= MAX_PLANES)
 return AVERROR(ENOSYS);
@@ -268,11 +269,11 @@ void ff_draw_color(FFDrawContext *draw, FFDrawColor 
*color, const uint8_t rgba[4
 EXPAND(1);
 EXPAND(0);
 } else if (draw->format == AV_PIX_FMT_GRAY8 || draw->format == 
AV_PIX_FMT_GRAY8A ||
-   draw->format == AV_PIX_FMT_GRAY16LE || draw->format == 
AV_PIX_FMT_YA16LE ||
-   draw->format == AV_PIX_FMT_GRAY9LE  ||
-   draw->format == AV_PIX_FMT_GRAY10LE ||
-   draw->format == AV_PIX_FMT_GRAY12LE ||
-   draw->format == AV_PIX_FMT_GRAY14LE) {
+   draw->format == AV_PIX_FMT_GRAY16 || draw->format == 
AV_PIX_FMT_YA16 ||
+   draw->format == AV_PIX_FMT_GRAY9  ||
+   draw->format == AV_PIX_FMT_GRAY10 ||
+   draw->format == AV_PIX_FMT_GRAY12 ||
+   draw->format == AV_PIX_FMT_GRAY14) {
 const AVPixFmtDescriptor *desc = draw->desc;
 color->comp[0].u8[0] = RGB_TO_Y_CCIR(rgba[0], rgba[1], rgba[2]);
 EXPAND(0);
@@ -331,11 +332,6 @@ void ff_fill_rectangle(FFDrawContext *draw, FFDrawColor 
*color,
 return;
 p = p0;
 
-if (HAVE_BIGENDIAN && draw->desc->comp[0].depth > 8) {
-for (x = 0; 2*x < draw->pixelstep[plane]; x++)
-color_tmp.comp[plane].u16[x] = 
av_bswap16(color_tmp.comp[plane].u16[x]);
-}
-
 /* copy first line from color */
 for (x = 0; x < wp; x++) {
 memcpy(p, color_tmp.comp[plane].u8, draw->pixelstep[plane]);
@@ -426,19 +422,19 @@ static void blend_line16(uint8_t *dst, unsigned src, 
unsigned alpha,
 
 if (left) {
 unsigned suba = (left * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 dst += dx;
 }
 for (x = 0; x < w; x++) {
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * tau + asrc) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * tau + asrc) >> 16);
 dst += dx;
 }
 if (right) {
 unsigned suba = (right * alpha) >> hsub;
-uint16_t value = AV_RL16(dst);
-AV_WL16(dst, (value * (0x10001 - suba) + src * suba) >> 16);
+uint16_t value = AV_RN16A(dst);
+AV_WN16A(dst, (value * (0x10001 - suba) + src * suba) >> 16);
 }
 }
 
@@ -531,7 +527,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src, 
unsigned alpha,
 unsigned xmmod = 7 >> l2depth;
 unsigned mbits = (1 << (1 << l2depth)) - 1;
 unsigned mmult = 255 / mbits;
-uint16_t value = AV_RL16(dst);
+uint16_t value = AV_RN16A(dst);
 
 for (y = 0; y < h; y++) {
 xm = xm0;
@@ -543,7 +539,7 @@ static void blend_pixel16(uint8_t *dst, unsigned src, 
unsigned alpha,
 mask += mask_linesize;
 }

[FFmpeg-devel] [PATCH v2 3/5] avfilter/vf_super2xsai: fix big-endian writing

2019-01-28 Thread Muhammad Faiz

Fix mismatched checksum on fate-filter-pixfmts-super2xsai.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/vf_super2xsai.c  |  4 ++--
 tests/ref/fate/filter-pixfmts-super2xsai | 16 
 2 files changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavfilter/vf_super2xsai.c b/libavfilter/vf_super2xsai.c
index 87eec04da8..4901e03e23 100644
--- a/libavfilter/vf_super2xsai.c
+++ b/libavfilter/vf_super2xsai.c
@@ -180,8 +180,8 @@ static void super2xsai(AVFilterContext *ctx,
 break;
 default: // bpp = 2
 if (s->is_be) {
-AV_WB32(dst_line[0] + x * 4, product1a | (product1b << 
16));
-AV_WB32(dst_line[1] + x * 4, product2a | (product2b << 
16));
+AV_WB32(dst_line[0] + x * 4, (product1a << 16) | 
product1b);
+AV_WB32(dst_line[1] + x * 4, (product2a << 16) | 
product2b);
 } else {
 AV_WL32(dst_line[0] + x * 4, product1a | (product1b << 
16));
 AV_WL32(dst_line[1] + x * 4, product2a | (product2b << 
16));
diff --git a/tests/ref/fate/filter-pixfmts-super2xsai 
b/tests/ref/fate/filter-pixfmts-super2xsai
index 04cf00dae4..6e9e1144d3 100644
--- a/tests/ref/fate/filter-pixfmts-super2xsai
+++ b/tests/ref/fate/filter-pixfmts-super2xsai
@@ -1,18 +1,18 @@
 abgre21be14b5fe9d7a29740a418c325b17e
 argb563489534663cb2b32beed2b41370c37
 bgr24   a933eac9bb53c3ce3c33950b229996b5
-bgr555bed6d14ec3ae9ed3006a253e9b9a9a
-bgr555be(le)d69e39a24027afcb28feaabb46f0948d
+bgr555bea293b0b4c6747b5b3f8fd4f9c4907ed1
+bgr555be(le)70b819425f79f823356229b90b41cc84
 bgr555le70b819425f79f823356229b90b41cc84
-bgr565be4ffcc26e740622ffd3314fe251e97804
-bgr565be(le)78f3b43ddcc1f8558444c97d249a6123
+bgr565beaa4a030327932a2c72dff315bf4d7385
+bgr565be(le)6fb9dc50a81b853800ba65d5ec6b8417
 bgr565le6fb9dc50a81b853800ba65d5ec6b8417
 bgrae9cc6644e2f35103c241094ab4bb8fec
 rgb24   3fd7653f414f350ddb0c0a236ce0c809
-rgb555be0f34c006142babd10065d90b8c2ce3d6
-rgb555be(le)f2f9f30e8be582729f12a03331e3c635
+rgb555be35860f8ca6c7e314dc3f658be6bb44ca
+rgb555be(le)53325a20c913826566880eb25d1d2946
 rgb555le53325a20c913826566880eb25d1d2946
-rgb565be9889faf1a636161f3049b78e92db7d89
-rgb565be(le)340ffed3645809f68346280764ca3de6
+rgb565be2c5adfea1c3843ca04355b0ccd293783
+rgb565be(le)14fe550f449a7539d9f1e99e85cf40f1
 rgb565le14fe550f449a7539d9f1e99e85cf40f1
 rgba7041184d35c316e73e849504b64bc4f6
-- 
2.17.2

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

[FFmpeg-devel] [PATCH v2 4/5] avfilter/vf_lut: support native-endian instead of little-endian

2019-01-28 Thread Muhammad Faiz

This should make code run faster on big-endian platform.
Change fate to use native-endian mode.

Signed-off-by: Muhammad Faiz 
---
 libavfilter/vf_lut.c  | 123 ++
 tests/fate/filter-video.mak   |   2 +-
 tests/ref/fate/filter-pixfmts-lut | 105 -
 3 files changed, 127 insertions(+), 103 deletions(-)

diff --git a/libavfilter/vf_lut.c b/libavfilter/vf_lut.c
index c815ddc194..c2bddfaaab 100644
--- a/libavfilter/vf_lut.c
+++ b/libavfilter/vf_lut.c
@@ -110,34 +110,34 @@ static av_cold void uninit(AVFilterContext *ctx)
 }
 }
 
-#define YUV_FORMATS \
-AV_PIX_FMT_YUV444P,  AV_PIX_FMT_YUV422P,  AV_PIX_FMT_YUV420P,\
-AV_PIX_FMT_YUV411P,  AV_PIX_FMT_YUV410P,  AV_PIX_FMT_YUV440P,\
-AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,   \
-AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ420P,   \
-AV_PIX_FMT_YUVJ440P, \
-AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV422P9LE, AV_PIX_FMT_YUV420P9LE, \
-AV_PIX_FMT_YUV444P10LE, AV_PIX_FMT_YUV422P10LE, AV_PIX_FMT_YUV420P10LE, 
AV_PIX_FMT_YUV440P10LE, \
-AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV422P12LE, AV_PIX_FMT_YUV420P12LE, 
AV_PIX_FMT_YUV440P12LE, \
-AV_PIX_FMT_YUV444P14LE, AV_PIX_FMT_YUV422P14LE, AV_PIX_FMT_YUV420P14LE, \
-AV_PIX_FMT_YUV444P16LE, AV_PIX_FMT_YUV422P16LE, AV_PIX_FMT_YUV420P16LE, \
-AV_PIX_FMT_YUVA444P16LE, AV_PIX_FMT_YUVA422P16LE, AV_PIX_FMT_YUVA420P16LE
-
-#define RGB_FORMATS \
-AV_PIX_FMT_ARGB, AV_PIX_FMT_RGBA, \
-AV_PIX_FMT_ABGR, AV_PIX_FMT_BGRA, \
-AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,\
-AV_PIX_FMT_RGB48LE,  AV_PIX_FMT_RGBA64LE, \
-AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,\
-AV_PIX_FMT_GBRP9LE,  AV_PIX_FMT_GBRP10LE, \
-AV_PIX_FMT_GBRAP10LE, \
-AV_PIX_FMT_GBRP12LE, AV_PIX_FMT_GBRP14LE, \
-AV_PIX_FMT_GBRP16LE, AV_PIX_FMT_GBRAP12LE,\
-AV_PIX_FMT_GBRAP16LE
-
-#define GRAY_FORMATS\
-AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY9LE, AV_PIX_FMT_GRAY10LE, \
-AV_PIX_FMT_GRAY12LE, AV_PIX_FMT_GRAY14LE, AV_PIX_FMT_GRAY16LE
+#define YUV_FORMATS
 \
+AV_PIX_FMT_YUV444P,AV_PIX_FMT_YUV422P,AV_PIX_FMT_YUV420P,  
 \
+AV_PIX_FMT_YUV411P,AV_PIX_FMT_YUV410P,AV_PIX_FMT_YUV440P,  
 \
+AV_PIX_FMT_YUVA420P,   AV_PIX_FMT_YUVA422P,   AV_PIX_FMT_YUVA444P, 
 \
+AV_PIX_FMT_YUVJ444P,   AV_PIX_FMT_YUVJ422P,   AV_PIX_FMT_YUVJ420P, 
 \
+AV_PIX_FMT_YUVJ440P,   
 \
+AV_PIX_FMT_YUV444P9,   AV_PIX_FMT_YUV422P9,   AV_PIX_FMT_YUV420P9, 
 \
+AV_PIX_FMT_YUV444P10,  AV_PIX_FMT_YUV422P10,  AV_PIX_FMT_YUV420P10, 
AV_PIX_FMT_YUV440P10, \
+AV_PIX_FMT_YUV444P12,  AV_PIX_FMT_YUV422P12,  AV_PIX_FMT_YUV420P12, 
AV_PIX_FMT_YUV440P12, \
+AV_PIX_FMT_YUV444P14,  AV_PIX_FMT_YUV422P14,  AV_PIX_FMT_YUV420P14,
 \
+AV_PIX_FMT_YUV444P16,  AV_PIX_FMT_YUV422P16,  AV_PIX_FMT_YUV420P16,
 \
+AV_PIX_FMT_YUVA444P16, AV_PIX_FMT_YUVA422P16, AV_PIX_FMT_YUVA420P16
+
+#define RGB_FORMATS \
+AV_PIX_FMT_ARGB,AV_PIX_FMT_RGBA,\
+AV_PIX_FMT_ABGR,AV_PIX_FMT_BGRA,\
+AV_PIX_FMT_RGB24,   AV_PIX_FMT_BGR24,   \
+AV_PIX_FMT_RGB48,   AV_PIX_FMT_RGBA64,  \
+AV_PIX_FMT_GBRP,AV_PIX_FMT_GBRAP,   \
+AV_PIX_FMT_GBRP9,   AV_PIX_FMT_GBRP10,  \
+AV_PIX_FMT_GBRAP10, \
+AV_PIX_FMT_GBRP12,  AV_PIX_FMT_GBRP14,  \
+AV_PIX_FMT_GBRP16,  AV_PIX_FMT_GBRAP12, \
+AV_PIX_FMT_GBRAP16
+
+#define GRAY_FORMATS \
+AV_PIX_FMT_GRAY8,  AV_PIX_FMT_GRAY9,  AV_PIX_FMT_GRAY10, \
+AV_PIX_FMT_GRAY12, AV_PIX_FMT_GRAY14, AV_PIX_FMT_GRAY16
 
 static const enum AVPixelFormat yuv_pix_fmts[] = { YUV_FORMATS, 
AV_PIX_FMT_NONE };
 static const enum AVPixelFormat rgb_pix_fmts[] = { RGB_FORMATS, 
AV_PIX_FMT_NONE };
@@ -237,32 +237,32 @@ static int config_props(AVFilterLink *inlink)
 case AV_PIX_FMT_YUVA420P:
 case AV_PIX_FMT_YUVA422P:
 case AV_PIX_FMT_YUVA444P:
-case AV_PIX_FMT_YUV420P9LE:
-case AV_PIX_FMT_YUV422P9LE:
-case AV_PIX_FMT_YUV444P9LE:
-case AV_PIX_FMT_YUVA420P9LE:
-case AV_PIX_FMT_YUVA422P9LE:
-case AV_PIX_FMT_YUVA444P9LE:
-case AV_PIX_FMT_YUV420P10LE:
-case AV_PIX_FMT_YUV422P10LE:
-case AV_PIX_FMT_YUV440P10LE:
-case AV_PIX_FMT_YUV444P10LE:
-case AV_PIX_FMT_YUVA420P10LE:
-case AV_PIX_FMT_YUVA422P10LE:
-case AV_PIX_FMT_YUVA444P10LE:
-case AV_PIX_FMT_YUV420P12LE:
-case AV_PIX_FMT_YUV422P12LE:
-case AV_PIX_FMT_YUV440P12LE:
-case AV_PIX_FMT_YUV444P12LE:
-case AV_PIX_FMT_YUV420P14LE:
-case AV_PIX_FMT_

[FFmpeg-devel] 971108 - ffmpeg doesn't use GPU

2019-01-28 Thread hamidi

I got the latest version binaries of ffmpeg from here
. When I examine CPU and GPU usages
when I play a video by its ffplay, I see that GPU is used during play. Not
much using of CPU also indicates it. But when I get the latest version
sources from the original site, I can't use GPU. To clarify, I include a
player test program I wrote until now. When I uncomment the line which
includes avcodec_find_decoder_by_name("h264_cuvid"), I get error -1. The
error happens in avcodec_open2 with the description of Operation not
permitted.

CString format(const char *fmt, ...)
{
va_list ap;
va_start(ap, fmt);
char buf[512];
vsnprintf(buf, sizeof(buf), fmt, ap);
va_end(ap);
return buf;
}

int CplayerDlg::play()
{
FILE *fp = fopen("video_files/1010.brf", "rb");
if (!fp)
{
AfxMessageBox("can't open video file");
return -1;
}
RecordFrame frame;
RecordHeader hdr;
fread(&frame, sizeof(frame), 1, fp);
if (frame.frameType != FRAME_TYPE_HEADER)
{
AfxMessageBox("record file doesn't begin with header");
return -1;
}
fread(&hdr, sizeof(hdr), 1, fp);
GetDlgItem(IDC_DIM)->SetWindowText(format("%dx%d", hdr.width,
hdr.height));
GetDlgItem(IDC_CODEC_ID)->SetWindowText(format("%d", hdr.codecId));
GetDlgItem(IDC_PIXEL_FORMAT)->SetWindowText(format("%d",
hdr.pixelFormat));
GetDlgItem(IDC_TIMEBASE)->SetWindowText(format("%d/%d",
hdr.timebaseNum, hdr.timebaseDen));
AVCodec *pCodec;

#if 0
#define CHECK(decoder)\
pCodec = avcodec_find_decoder_by_name(#decoder);\
AfxMessageBox(pCodec ? #decoder " found" : "can't find " #decoder);

CHECK(h264_cuvid);

#undef CHECK
#endif

pCodec = avcodec_find_decoder(AV_CODEC_ID_H264);
//pCodec = avcodec_find_decoder_by_name("h264_cuvid");
if (!pCodec)
{
AfxMessageBox("can't find h264 decoder");
return -1;
}

AVCodecContext *pCodecContext = avcodec_alloc_context3(pCodec);
if (!pCodecContext)
{
AfxMessageBox("can't allocate codec context");
return -1;
}

#if 0
// enumerating available codecs
//av_register_all();
avcodec_register_all();

AVCodec *current_codec = av_codec_next(NULL);
while (current_codec != NULL)
{
TRACE("%s\n", current_codec->name);
current_codec = av_codec_next(current_codec);
}
#endif

int err = avcodec_open2(pCodecContext, pCodec, NULL);
if (err != 0)
{
char buf[AV_ERROR_MAX_STRING_SIZE];
av_make_error_string(buf, AV_ERROR_MAX_STRING_SIZE, err);
char buf2[AV_ERROR_MAX_STRING_SIZE];
sprintf(buf2, "%d (%x): %s\n", err, err, buf);
AfxMessageBox(buf2);
return -1;
}
AfxMessageBox("operation completed successfully");
fclose(fp);
return 0;
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Carl Eugen Hoyos

Hi!

Attached patch fixes the actual output duration for AMR-WB samples
with NO_DATA frames.
A follow-up patch also skips corrupted frames, making the output of
the sample in ticket #7113 very similar to the reference decoder.

Please comment, Carl Eugen
From ab817b2c8fc96ddabc8238c9be2beed04cd54512 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Mon, 28 Jan 2019 15:10:13 +0100
Subject: [PATCH] lavc/amrwbdec: Do not ignore NO_DATA frames.

Fixes the actual output duration of the sample in ticket #7113.
---
 libavcodec/amrwbdata.h |2 +-
 libavcodec/amrwbdec.c  |7 ++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavcodec/amrwbdata.h b/libavcodec/amrwbdata.h
index 8a8cbfd..95c0aaa 100644
--- a/libavcodec/amrwbdata.h
+++ b/libavcodec/amrwbdata.h
@@ -1884,7 +1884,7 @@ static const float lpf_7_coef[31] = { // low pass, 7kHz cutoff
 /** Core frame sizes in each mode */
 static const uint16_t cf_sizes_wb[] = {
 132, 177, 253, 285, 317, 365, 397, 461, 477,
-40 /// SID/comfort noise frame
+40, 0, 0, 0, 0, 0, 0
 };
 
 #endif /* AVCODEC_AMRWBDATA_H */
diff --git a/libavcodec/amrwbdec.c b/libavcodec/amrwbdec.c
index 47fe7eb..997b3e8 100644
--- a/libavcodec/amrwbdec.c
+++ b/libavcodec/amrwbdec.c
@@ -1119,12 +1119,17 @@ static int amrwb_decode_frame(AVCodecContext *avctx, void *data,
 buf_out = (float *)frame->data[0];
 
 header_size  = decode_mime_header(ctx, buf);
+expected_fr_size = ((cf_sizes_wb[ctx->fr_cur_mode] + 7) >> 3) + 1;
+
+if (ctx->fr_cur_mode == NO_DATA) {
+*got_frame_ptr = 1;
+return expected_fr_size;
+}
 if (ctx->fr_cur_mode > MODE_SID) {
 av_log(avctx, AV_LOG_ERROR,
"Invalid mode %d\n", ctx->fr_cur_mode);
 return AVERROR_INVALIDDATA;
 }
-expected_fr_size = ((cf_sizes_wb[ctx->fr_cur_mode] + 7) >> 3) + 1;
 
 if (buf_size < expected_fr_size) {
 av_log(avctx, AV_LOG_ERROR,
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Paul B Mahol

On 1/28/19, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes the actual output duration for AMR-WB samples
> with NO_DATA frames.
> A follow-up patch also skips corrupted frames, making the output of
> the sample in ticket #7113 very similar to the reference decoder.
>
> Please comment, Carl Eugen
>

Very similar does not mean much!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Carl Eugen Hoyos

2019-01-28 15:20 GMT+01:00, Paul B Mahol :
> On 1/28/19, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes the actual output duration for AMR-WB samples
>> with NO_DATA frames.
>> A follow-up patch also skips corrupted frames, making the output of
>> the sample in ticket #7113 very similar to the reference decoder.
>
> Very similar does not mean much!

Since some frames are broken (and not just corrupted) and the
codec uses floats internally, I don't think this is relevant.

In addition, this patch is not about similarity in the output but
duration, so your comment does not apply here.

Is this patch ok?

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

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Paul B Mahol

On 1/28/19, Carl Eugen Hoyos  wrote:
> 2019-01-28 15:20 GMT+01:00, Paul B Mahol :
>> On 1/28/19, Carl Eugen Hoyos  wrote:
>>> Hi!
>>>
>>> Attached patch fixes the actual output duration for AMR-WB samples
>>> with NO_DATA frames.
>>> A follow-up patch also skips corrupted frames, making the output of
>>> the sample in ticket #7113 very similar to the reference decoder.
>>
>> Very similar does not mean much!
>
> Since some frames are broken (and not just corrupted) and the
> codec uses floats internally, I don't think this is relevant.
>
> In addition, this patch is not about similarity in the output but
> duration, so your comment does not apply here.
>
> Is this patch ok?

Only if you can confirm that output is same as reference decoder
expect rounding.

so use 16bit sample format and rounding error should be max -1/+1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Carl Eugen Hoyos

2019-01-28 16:17 GMT+01:00, Paul B Mahol :
> On 1/28/19, Carl Eugen Hoyos  wrote:
>> 2019-01-28 15:20 GMT+01:00, Paul B Mahol :
>>> On 1/28/19, Carl Eugen Hoyos  wrote:
 Hi!

 Attached patch fixes the actual output duration for AMR-WB samples
 with NO_DATA frames.
 A follow-up patch also skips corrupted frames, making the output of
 the sample in ticket #7113 very similar to the reference decoder.
>>>
>>> Very similar does not mean much!
>>
>> Since some frames are broken (and not just corrupted) and the
>> codec uses floats internally, I don't think this is relevant.
>>
>> In addition, this patch is not about similarity in the output but
>> duration, so your comment does not apply here.
>>
>> Is this patch ok?
>
> Only if you can confirm that output is same as reference decoder
> expect rounding.

Sorry for the misunderstanding:
This patch does not aim to make the output more similar to
any other decoder, it only fixes the actual output duration
when decoding.

Please comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] 971108 - ffmpeg doesn't use GPU

2019-01-28 Thread Timo Rothenpieler


This list is about development of ffmpeg itself.
You are probably looking for libav-users.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/arbc: clear decoder state when seeking

2019-01-28 Thread James Almer

Signed-off-by: James Almer 
---
 libavcodec/arbc.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
index 01a146f934..4558304f12 100644
--- a/libavcodec/arbc.c
+++ b/libavcodec/arbc.c
@@ -181,6 +181,13 @@ static av_cold int decode_init(AVCodecContext *avctx)
 return 0;
 }
 
+static void decode_flush(AVCodecContext *avctx)
+{
+ARBCContext *s = avctx->priv_data;
+
+av_frame_unref(s->prev_frame);
+}
+
 static av_cold int decode_close(AVCodecContext *avctx)
 {
 ARBCContext *s = avctx->priv_data;
@@ -198,6 +205,7 @@ AVCodec ff_arbc_decoder = {
 .priv_data_size = sizeof(ARBCContext),
 .init   = decode_init,
 .decode = decode_frame,
+.flush  = decode_flush,
 .close  = decode_close,
 .capabilities   = AV_CODEC_CAP_DR1,
 .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Paul B Mahol

On 1/28/19, Carl Eugen Hoyos  wrote:
> 2019-01-28 16:17 GMT+01:00, Paul B Mahol :
>> On 1/28/19, Carl Eugen Hoyos  wrote:
>>> 2019-01-28 15:20 GMT+01:00, Paul B Mahol :
 On 1/28/19, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes the actual output duration for AMR-WB samples
> with NO_DATA frames.
> A follow-up patch also skips corrupted frames, making the output of
> the sample in ticket #7113 very similar to the reference decoder.

 Very similar does not mean much!
>>>
>>> Since some frames are broken (and not just corrupted) and the
>>> codec uses floats internally, I don't think this is relevant.
>>>
>>> In addition, this patch is not about similarity in the output but
>>> duration, so your comment does not apply here.
>>>
>>> Is this patch ok?
>>
>> Only if you can confirm that output is same as reference decoder
>> expect rounding.
>
> Sorry for the misunderstanding:
> This patch does not aim to make the output more similar to
> any other decoder, it only fixes the actual output duration
> when decoding.
>

Than patch is incorrect.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/arbc: clear decoder state when seeking

2019-01-28 Thread Paul B Mahol

On 1/28/19, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavcodec/arbc.c | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/arbc.c b/libavcodec/arbc.c
> index 01a146f934..4558304f12 100644
> --- a/libavcodec/arbc.c
> +++ b/libavcodec/arbc.c
> @@ -181,6 +181,13 @@ static av_cold int decode_init(AVCodecContext *avctx)
>  return 0;
>  }
>
> +static void decode_flush(AVCodecContext *avctx)
> +{
> +ARBCContext *s = avctx->priv_data;
> +
> +av_frame_unref(s->prev_frame);
> +}
> +
>  static av_cold int decode_close(AVCodecContext *avctx)
>  {
>  ARBCContext *s = avctx->priv_data;
> @@ -198,6 +205,7 @@ AVCodec ff_arbc_decoder = {
>  .priv_data_size = sizeof(ARBCContext),
>  .init   = decode_init,
>  .decode = decode_frame,
> +.flush  = decode_flush,
>  .close  = decode_close,
>  .capabilities   = AV_CODEC_CAP_DR1,
>  .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

[FFmpeg-devel] configure: Fix decklink license dependency

2019-01-28 Thread Elliott Balsley

I see this old thread about Decklink licensing, and I disagree with the nonfree 
requirement.
I can’t figure out how to reply to the old thread, but here it is for 
reference: https://patchwork.ffmpeg.org/patch/3230/ 

Downloading the SDK from Blackmagic uses a EULA which prevents distribution, 
but each individual header file contains a more permissive Boost license.  So 
apparently, the only part of the SDK covered by the restrictive EULA is the PDF 
documentation.  This means the headers could even be included in the ffmpeg 
GitHub if you desire.

I emailed Blackmagic to clarify this, and here is their response:
There is no fee to use the DeckLink SDK. Access to the DeckLink SDK is governed 
by the EULA and is only available from the Blackmagic Design website. 
Applications that are built with the SDK are then licensed via the more 
permissive license contained within the SDK.

It is Blackmagic Design policy that there should only be one publicly available 
source for the SDK (i.e. the Blackmagic Design website) and in order to 
download the SDK the EULA must be agreed to. 

In addition, distribution of the SDK is prohibited as per the EULA ("The 
Licensee must not lease, rent, distribute or sub-license the Software, or use 
the Software in a time-sharing arrangement, or in any other manner that is not 
the Permitted Use.”)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-01-28 Thread Marvin Scholz


On 28 Jan 2019, at 21:09, Elliott Balsley wrote:

I see this old thread about Decklink licensing, and I disagree with 
the nonfree requirement.
I can’t figure out how to reply to the old thread, but here it is 
for reference: https://patchwork.ffmpeg.org/patch/3230/ 

Downloading the SDK from Blackmagic uses a EULA which prevents 
distribution, but each individual header file contains a more 
permissive Boost license.  So apparently, the only part of the SDK 
covered by the restrictive EULA is the PDF documentation.  This means 
the headers could even be included in the ffmpeg GitHub if you desire.


I emailed Blackmagic to clarify this, and here is their response:
There is no fee to use the DeckLink SDK. Access to the DeckLink SDK is 
governed by the EULA and is only available from the Blackmagic Design 
website. Applications that are built with the SDK are then licensed 
via the more permissive license contained within the SDK.


It is Blackmagic Design policy that there should only be one publicly 
available source for the SDK (i.e. the Blackmagic Design website) and 
in order to download the SDK the EULA must be agreed to.


In addition, distribution of the SDK is prohibited as per the EULA


This is in conflicts with the license of individual header files in the 
SDK, so does it mean
that the header files with the more permissive license overrule the 
EULA?

It would be great to have Blackmagic clarify this.

It is very confusing to prohibit people from distributing files with the 
EULA while stating
in some of these files that distributing them is fine... So while 
according to the license
in the files distributing them would be fine, you would violate the EULA 
by doing so.


("The Licensee must not lease, rent, distribute or sub-license the 
Software, or use the Software in a time-sharing arrangement, or in any 
other manner that is not the Permitted Use.”)





___
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 v2 09/11] vaapi_encode: Add support for VFR mode

2019-01-28 Thread Michael Niedermayer

On Sun, Jan 27, 2019 at 11:47:05PM +, Mark Thompson wrote:
> Use the frame-skip feature to maintain a specified framerate from the
> point of view of the driver.
> ---
>  doc/encoders.texi |   7 +++
>  libavcodec/vaapi_encode.c | 116 +++---
>  libavcodec/vaapi_encode.h |  18 +-
>  3 files changed, 132 insertions(+), 9 deletions(-)

seems to break build

CC  libavcodec/vaapi_encode.o
libavcodec/vaapi_encode.c: In function ‘vaapi_encode_init_framerate’:
libavcodec/vaapi_encode.c:1718:12: error: ‘VAAPIEncodeContext’ has no member 
named ‘max_fps’
 if (ctx->max_fps.num > 0 && ctx->max_fps.den > 0) {
^
libavcodec/vaapi_encode.c:1718:36: error: ‘VAAPIEncodeContext’ has no member 
named ‘max_fps’
 if (ctx->max_fps.num > 0 && ctx->max_fps.den > 0) {
^
make: *** [libavcodec/vaapi_encode.o] Error 1
make: Target `all' not remade because of errors.

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

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

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

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

2019-01-28 Thread Marton Balint




On Mon, 28 Jan 2019, Gyan wrote:




On 28-01-2019 01:53 PM, Marton Balint wrote:

From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 28 Jan 2019 12:20:02 +0530
Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
 missing CRLF

---
 libavformat/http.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 240304f6e6..2f2ce856bc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char 
*uri, int flags,

 int len = strlen(s->headers);
 if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
 av_log(h, AV_LOG_WARNING,
-   "No trailing CRLF found in HTTP header.\n");
+   "No trailing CRLF found in HTTP header. Adding 
it.\n");

 ret = av_reallocp(&s->headers, len + 3);
-    if (ret < 0)
+    if (ret < 0) {
+    av_log(h, AV_LOG_ERROR,
+   "Failed to add trailing CRLF.\n");

In general I am against adding messages for ENOMEM cases.


The codepath above is contingent upon malformed user input, and not a 
routine alloc.
Log message is extended to inform the user we're 
correcting the header.  So I consider it good practice to report its 
failure, rather than leaving it opaque.


You do report failure with the returned error code. I really don't see a 
case where it actually helps the user in any way to know that memory 
exhausted there and not before. Therefore the "Failed to add trailing 
CRLF" message is useless.


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

Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function

2019-01-28 Thread Marton Balint




On Thu, 24 Jan 2019, Michael Niedermayer wrote:


On Thu, Jan 24, 2019 at 10:23:33PM +0100, Marton Balint wrote:



On Sun, 20 Jan 2019, Michael Niedermayer wrote:


On Sun, Jan 20, 2019 at 07:35:18PM +0100, Marton Balint wrote:



On Sun, 20 Jan 2019, Michael Niedermayer wrote:


On Sat, Jan 19, 2019 at 11:48:39PM +0100, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
libavcodec/motion_est.c  |  4 +--
libavcodec/motion_est_template.c | 62 +---
2 files changed, 3 insertions(+), 63 deletions(-)


please check if the compiler optimizes the size constant out after this
change


The compiler inlines the function before and after the change as well. I
can't see notable changes in the disassembly of interlaced_search and
h263_mv4_search. Is this enough, or something else should be checked? I am
not sure how...


If the inlined code is used with only one size value then its probably ok.
you could also put some marker with asm() in the code where size is used
and then look at the .s file generated if the size is optimized out or
still read as a variable


I checked the .s file and a constant is pushed to the stack as the size
parameter when funny_diamond_search is called in h263_mv4_search and
interlaced_search.

So yes, the size parameter is still optimized as a constant in the touched
functions.


i guess its ok then


Thanks, applied.

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

Re: [FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

2019-01-28 Thread Michael Niedermayer

On Mon, Jan 28, 2019 at 05:07:38PM +0700, Muhammad Faiz wrote:
> Fix inconsistent checksums between gbrap10be and gbrap10le
> on fate-filter-pixfmts.
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  libswscale/swscale_unscaled.c| 3 +++
>  tests/ref/fate/filter-pixfmts-copy   | 2 +-
>  tests/ref/fate/filter-pixfmts-crop   | 2 +-
>  tests/ref/fate/filter-pixfmts-field  | 2 +-
>  tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
>  tests/ref/fate/filter-pixfmts-hflip  | 2 +-
>  tests/ref/fate/filter-pixfmts-il | 2 +-
>  tests/ref/fate/filter-pixfmts-null   | 2 +-
>  tests/ref/fate/filter-pixfmts-scale  | 2 +-
>  tests/ref/fate/filter-pixfmts-transpose  | 2 +-
>  tests/ref/fate/filter-pixfmts-vflip  | 2 +-
>  11 files changed, 13 insertions(+), 10 deletions(-)
> 
> diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> index 058f2b94db..734a527e68 100644
> --- a/libswscale/swscale_unscaled.c
> +++ b/libswscale/swscale_unscaled.c
> @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
>   dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == 
> AV_PIX_FMT_GBRP12BE ||
>   dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == 
> AV_PIX_FMT_GBRP14BE ||
>   dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == 
> AV_PIX_FMT_GBRP16BE ||
> + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
> AV_PIX_FMT_GBRAP10BE ||
>   dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
> AV_PIX_FMT_GBRAP12BE ||
>   dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
> AV_PIX_FMT_GBRAP16BE ))
>  c->swscale = Rgb16ToPlanarRgb16Wrapper;
> @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
>   srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == 
> AV_PIX_FMT_GBRP10BE ||
>   srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == 
> AV_PIX_FMT_GBRP12BE ||
>   srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == 
> AV_PIX_FMT_GBRP14BE ||
> + srcFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == 
> AV_PIX_FMT_GBRAP10BE ||
>   srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
> AV_PIX_FMT_GBRAP12BE ||
>   srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
> AV_PIX_FMT_GBRAP16BE) &&
>  (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == AV_PIX_FMT_RGB48BE 
>  ||
> @@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
> +IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
>  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||

have you tested these ?
iam asking as the previous iteration had a bug which was missed in testing
also adding a test or tests to fate which would cover that codepath that was
missed could be a good idea

the change itself looks fine i think but i have not tested it beyond seeing
that it changes the output for some files

Thanks

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

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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

Re: [FFmpeg-devel] [PATCH v2 1/5] test/fate-run: duplicate pixfmts test when format is big-endian or native-endian

2019-01-28 Thread Michael Niedermayer

On Mon, Jan 28, 2019 at 05:07:37PM +0700, Muhammad Faiz wrote:
> When format is big-endian, also output little-endian checksum.
> This allows consistent checksum between little-endian and big-endian.
> 
> When format is native-endian (by passing parameter to pixfmts),
> output both little/big-endian. This allows invariant ouputs
> between little-endian and big-endian platform.
> 
> This reveals some bugs in libswscale (mismatched checksum
> between little-endian and big-endian on gbrap10, p010, and p016),
> and libavfilter (mismatched checksum between little-endian
> and big-endian on super2xsai filter).
> 
> Eventough this patch reveals bugs in libswscale, it does not
> mean to test libswscale. A complete separate solution to address
> it (e.g adding test to make sure that all lossless coversions
> are actually lossless) is beyond of this patch.
> 
> Signed-off-by: Muhammad Faiz 
> ---
>  tests/fate-run.sh| 22 +-
>  tests/ref/fate/filter-pixfmts-copy   | 56 
>  tests/ref/fate/filter-pixfmts-crop   | 56 
>  tests/ref/fate/filter-pixfmts-field  | 56 
>  tests/ref/fate/filter-pixfmts-fieldorder | 44 +++
>  tests/ref/fate/filter-pixfmts-hflip  | 56 
>  tests/ref/fate/filter-pixfmts-il | 56 
>  tests/ref/fate/filter-pixfmts-null   | 56 
>  tests/ref/fate/filter-pixfmts-scale  | 56 
>  tests/ref/fate/filter-pixfmts-super2xsai |  4 ++
>  tests/ref/fate/filter-pixfmts-swapuv | 28 
>  tests/ref/fate/filter-pixfmts-transpose  | 45 +++
>  tests/ref/fate/filter-pixfmts-vflip  | 56 
>  13 files changed, 589 insertions(+), 2 deletions(-)
> 
> diff --git a/tests/fate-run.sh b/tests/fate-run.sh
> index aece90a01d..dc4619e59c 100755
> --- a/tests/fate-run.sh
> +++ b/tests/fate-run.sh
> @@ -280,6 +280,7 @@ pixfmts(){
>  filter_args=$1
>  prefilter_chain=$2
>  nframes=${3:-1}
> +native_endian=$4
>  
>  showfiltfmts="$target_exec $target_path/libavfilter/tests/filtfmts"
>  scale_exclude_fmts=${outfile}_scale_exclude_fmts
> @@ -297,8 +298,25 @@ pixfmts(){
>  
>  outertest=$test
>  for pix_fmt in $pix_fmts; do
> -test=$pix_fmt
> -video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt 
> -frames:v $nframes
> +pix_fmt_le=`echo $pix_fmt | sed 's/be$/le/'`
> +pix_fmt_be=`echo $pix_fmt | sed 's/le$/be/'`
> +if test "$pix_fmt_le" = "$pix_fmt_be"; then
> +test=$pix_fmt
> +video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt 
> -frames:v $nframes
> +elif test -n "$native_endian"; then
> +pix_fmt_ne=`echo $pix_fmt_le | sed 's/le$//'`
> +test="$pix_fmt_ne(be)"
> +video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args,format=$pix_fmt" 
> -pix_fmt $pix_fmt_be -frames:v $nframes
> +test="$pix_fmt_ne(le)"
> +video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args,format=$pix_fmt" 
> -pix_fmt $pix_fmt_le -frames:v $nframes
> +else
> +test=$pix_fmt
> +video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args" -pix_fmt $pix_fmt 
> -frames:v $nframes
> +if test "$pix_fmt_be" = "$pix_fmt"; then
> +test="$pix_fmt(le)"
> +video_filter 
> "${prefilter_chain}format=$pix_fmt,$filter=$filter_args,format=$pix_fmt" 
> -pix_fmt $pix_fmt_le -frames:v $nframes
> +fi
> +fi
>  done

looks better

thanks!

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

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


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

[FFmpeg-devel] [PATCH] avcodec/pgssubdec: Check for duplicate display segments

2019-01-28 Thread Michael Niedermayer

In such a duplication the previous gets overwritten and leaks

Fixes: memleak
Fixes: 
12510/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGSSUB_fuzzer-5694439226343424

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/pgssubdec.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/pgssubdec.c b/libavcodec/pgssubdec.c
index b897d72aab..8c10f6d573 100644
--- a/libavcodec/pgssubdec.c
+++ b/libavcodec/pgssubdec.c
@@ -676,6 +676,11 @@ static int decode(AVCodecContext *avctx, void *data, int 
*data_size,
  */
 break;
 case DISPLAY_SEGMENT:
+if (*data_size) {
+av_log(avctx, AV_LOG_ERROR, "Duplicate display segment\n");
+ret = AVERROR_INVALIDDATA;
+break;
+}
 ret = display_end_segment(avctx, data, buf, segment_length);
 if (ret >= 0)
 *data_size = ret;
-- 
2.20.1

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

Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-01-28 Thread Elliott Balsley

In the first paragraph of the EULA, they define “the software” as the SDK and 
the accompanying documentation.  The way I read it, they do not want you to 
distribute the complete SDK package, specifically the PDF documentation file.  
But the email I quoted below from Blackmagic explicitly states that 
"Applications that are built with the SDK are then licensed via the more 
permissive license contained within the SDK"


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

[FFmpeg-devel] [PATCH] avcodec/libx264: update notes to explain the scale chosen for ROI encoding

2019-01-28 Thread Guo, Yejun

Signed-off-by: Guo, Yejun 
---
 libavcodec/libx264.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index a3493f3..8c96728 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -383,7 +383,9 @@ static int X264_frame(AVCodecContext *ctx, AVPacket *pkt, 
const AVFrame *frame,
 qoffset = roi->qoffset.num * 1.0f / roi->qoffset.den;
 qoffset = av_clipf(qoffset, -1.0f, 1.0f);
 
-// 25 is a number that I think it is a possible proper 
scale value.
+/* qp range of x264 is from 0 to 51, just choose 25 as 
the scale value,
+ * so the range of final qoffset is [-25.0, 25.0].
+ */
 qoffset = qoffset * 25;
 
 for (int y = starty; y < endy; y++) {
-- 
2.7.4

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

Re: [FFmpeg-devel] configure: Fix decklink license dependency

2019-01-28 Thread Carl Eugen Hoyos

2019-01-28 21:09 GMT+01:00, Elliott Balsley :
> I see this old thread about Decklink licensing, and I disagree with the
> nonfree requirement.

Great!
Do you speak for all FFmpeg developers or only for your commits?


> I can’t figure out how to reply to the old thread, but here it is for
> reference: https://patchwork.ffmpeg.org/patch/3230/
> 
> Downloading the SDK from Blackmagic uses a EULA which prevents distribution,
> but each individual header file contains a more permissive Boost license.
> So apparently, the only part of the SDK covered by the restrictive EULA is
> the PDF documentation.  This means the headers could even be included in the
> ffmpeg GitHub if you desire.

This is not about the headers (I am sorry if I did give this impression
at any point), but about the library that is loaded at runtime by FFmpeg.
As long as this library is closed-source, this discussion leads nowhere.

> I emailed Blackmagic to clarify this

You misunderstand:
It is not Blackmagic who does not want you to distribute FFmpeg
with their (proprietary) library, it is us who do not allow distribution
of FFmpeg binaries that link against Blackmagic libraries.

You cannot change this (we cannot either), please understand that
we should all invest our time in different issues.

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

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

2019-01-28 Thread Carl Eugen Hoyos

2019-01-28 19:40 GMT+01:00, Paul B Mahol :
> On 1/28/19, Carl Eugen Hoyos  wrote:
>> 2019-01-28 16:17 GMT+01:00, Paul B Mahol :
>>> On 1/28/19, Carl Eugen Hoyos  wrote:
 2019-01-28 15:20 GMT+01:00, Paul B Mahol :
> On 1/28/19, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> Attached patch fixes the actual output duration for AMR-WB samples
>> with NO_DATA frames.
>> A follow-up patch also skips corrupted frames, making the output of
>> the sample in ticket #7113 very similar to the reference decoder.
>
> Very similar does not mean much!

 Since some frames are broken (and not just corrupted) and the
 codec uses floats internally, I don't think this is relevant.

 In addition, this patch is not about similarity in the output but
 duration, so your comment does not apply here.

 Is this patch ok?
>>>
>>> Only if you can confirm that output is same as reference decoder
>>> expect rounding.
>>
>> Sorry for the misunderstanding:
>> This patch does not aim to make the output more similar to
>> any other decoder, it only fixes the actual output duration
>> when decoding.
>
> Than patch is incorrect.

I don't understand:
We have a sample that decodes with too short duration with current
FFmpeg, the patch fixes this: Why is the patch incorrect?

I realize now that by fixing the "missing" parts in the output file, it of
course does make the file (significantly) more similar to the
reference output - but it does not change the parts of the output
that were already there.

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

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

2019-01-28 Thread Carl Eugen Hoyos

2019-01-28 9:23 GMT+01:00, Marton Balint :
> From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Mon, 28 Jan 2019 12:20:02 +0530
> Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
>   missing CRLF
>
> ---
>   libavformat/http.c | 7 +--
>   1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 240304f6e6..2f2ce856bc 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char *uri,
> int flags,
>   int len = strlen(s->headers);
>   if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
>   av_log(h, AV_LOG_WARNING,
> -   "No trailing CRLF found in HTTP header.\n");
> +   "No trailing CRLF found in HTTP header. Adding it.\n");
>   ret = av_reallocp(&s->headers, len + 3);
> -if (ret < 0)
> +if (ret < 0) {
> +av_log(h, AV_LOG_ERROR,
> +   "Failed to add trailing CRLF.\n");
>
> In general I am against adding messages for ENOMEM cases.

+1

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

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

2019-01-28 Thread Gyan




On 29-01-2019 02:31 AM, Marton Balint wrote:



On Mon, 28 Jan 2019, Gyan wrote:




On 28-01-2019 01:53 PM, Marton Balint wrote:

From bc08c60761df77b37c83a4c285f3ca45e5045979 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Mon, 28 Jan 2019 12:20:02 +0530
Subject: [PATCH] avformat/http: clarify that ffmpeg will attempt to add
 missing CRLF

---
 libavformat/http.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 240304f6e6..2f2ce856bc 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -541,10 +541,13 @@ static int http_open(URLContext *h, const char 
*uri, int flags,

 int len = strlen(s->headers);
 if (len < 2 || strcmp("\r\n", s->headers + len - 2)) {
 av_log(h, AV_LOG_WARNING,
-   "No trailing CRLF found in HTTP header.\n");
+   "No trailing CRLF found in HTTP header. Adding 
it.\n");

 ret = av_reallocp(&s->headers, len + 3);
-    if (ret < 0)
+    if (ret < 0) {
+    av_log(h, AV_LOG_ERROR,
+   "Failed to add trailing CRLF.\n");

In general I am against adding messages for ENOMEM cases.


The codepath above is contingent upon malformed user input, and not a 
routine alloc.
Log message is extended to inform the user we're correcting the 
header.  So I consider it good practice to report its failure, rather 
than leaving it opaque.


You do report failure with the returned error code. I really don't see 
a case where it actually helps the user in any way to know that memory 
exhausted there and not before. Therefore the "Failed to add trailing 
CRLF" message is useless.


Ok, will remove and push.

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

Re: [FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

2019-01-28 Thread Muhammad Faiz

On Tue, Jan 29, 2019 at 5:14 AM Michael Niedermayer
 wrote:
>
> On Mon, Jan 28, 2019 at 05:07:38PM +0700, Muhammad Faiz wrote:
> > Fix inconsistent checksums between gbrap10be and gbrap10le
> > on fate-filter-pixfmts.
> >
> > Signed-off-by: Muhammad Faiz 
> > ---
> >  libswscale/swscale_unscaled.c| 3 +++
> >  tests/ref/fate/filter-pixfmts-copy   | 2 +-
> >  tests/ref/fate/filter-pixfmts-crop   | 2 +-
> >  tests/ref/fate/filter-pixfmts-field  | 2 +-
> >  tests/ref/fate/filter-pixfmts-fieldorder | 2 +-
> >  tests/ref/fate/filter-pixfmts-hflip  | 2 +-
> >  tests/ref/fate/filter-pixfmts-il | 2 +-
> >  tests/ref/fate/filter-pixfmts-null   | 2 +-
> >  tests/ref/fate/filter-pixfmts-scale  | 2 +-
> >  tests/ref/fate/filter-pixfmts-transpose  | 2 +-
> >  tests/ref/fate/filter-pixfmts-vflip  | 2 +-
> >  11 files changed, 13 insertions(+), 10 deletions(-)
> >
> > diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
> > index 058f2b94db..734a527e68 100644
> > --- a/libswscale/swscale_unscaled.c
> > +++ b/libswscale/swscale_unscaled.c
> > @@ -1942,6 +1942,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   dstFormat == AV_PIX_FMT_GBRP12LE || dstFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRP14LE || dstFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> >   dstFormat == AV_PIX_FMT_GBRP16LE || dstFormat == 
> > AV_PIX_FMT_GBRP16BE ||
> > + dstFormat == AV_PIX_FMT_GBRAP10LE || dstFormat == 
> > AV_PIX_FMT_GBRAP10BE ||
> >   dstFormat == AV_PIX_FMT_GBRAP12LE || dstFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   dstFormat == AV_PIX_FMT_GBRAP16LE || dstFormat == 
> > AV_PIX_FMT_GBRAP16BE ))
> >  c->swscale = Rgb16ToPlanarRgb16Wrapper;
> > @@ -1951,6 +1952,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >   srcFormat == AV_PIX_FMT_GBRP10LE || srcFormat == 
> > AV_PIX_FMT_GBRP10BE ||
> >   srcFormat == AV_PIX_FMT_GBRP12LE || srcFormat == 
> > AV_PIX_FMT_GBRP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRP14LE || srcFormat == 
> > AV_PIX_FMT_GBRP14BE ||
> > + srcFormat == AV_PIX_FMT_GBRAP10LE || srcFormat == 
> > AV_PIX_FMT_GBRAP10BE ||
> >   srcFormat == AV_PIX_FMT_GBRAP12LE || srcFormat == 
> > AV_PIX_FMT_GBRAP12BE ||
> >   srcFormat == AV_PIX_FMT_GBRAP16LE || srcFormat == 
> > AV_PIX_FMT_GBRAP16BE) &&
> >  (dstFormat == AV_PIX_FMT_RGB48LE  || dstFormat == 
> > AV_PIX_FMT_RGB48BE  ||
> > @@ -1997,6 +1999,7 @@ void ff_get_unscaled_swscale(SwsContext *c)
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP12) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP14) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRP16) ||
> > +IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP10) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP12) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_GBRAP16) ||
> >  IS_DIFFERENT_ENDIANESS(srcFormat, dstFormat, AV_PIX_FMT_RGB444) ||
>
> have you tested these ?
> iam asking as the previous iteration had a bug which was missed in testing

fate-filter-pixfmts only covers gbrap10le <-> gbrap10be conversion.
Actually the first two changes fix gbrap10 <-> rgb(a)(64/48) conversions.

This is a simple test:
FFMPEG=./ffmpeg

$FFMPEG -loglevel quiet -filter_complex "allyuv=d=0.01" -pix_fmt
gbrap10le -f rawvideo -y in.rgb

for fmt in rgba64be bgra64be rgba64le bgra64be gbrap10be; do
$FFMPEG -loglevel quiet -s 4096x4096 -pix_fmt gbrap10le -f
rawvideo -i in.rgb -vf format=$fmt -pix_fmt gbrap10le -f rawvideo -y
out-$fmt.rgb
if cmp in.rgb out-$fmt.rgb; then
echo "in.rgb out-$fmt.rgb are equal"
fi
done

> also adding a test or tests to fate which would cover that codepath that was
> missed could be a good idea

As I suggested in 1/5, adding a test that covers all lossless
conversions (not only gbrap10 case) is a good idea.
But that is beyond of this patch.

(Also note that p010 and p016 problems haven't yet been fixed.)

>
> the change itself looks fine i think but i have not tested it beyond seeing
> that it changes the output for some files
>
> Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

[FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

[FFmpeg-devel] [PATCH v2 5/5] avfilter/drawutils: support native-endian instead of little-endian

[FFmpeg-devel] [PATCH v2 3/5] avfilter/vf_super2xsai: fix big-endian writing

[FFmpeg-devel] [PATCH v2 4/5] avfilter/vf_lut: support native-endian instead of little-endian

[FFmpeg-devel] 971108 - ffmpeg doesn't use GPU

[FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] 971108 - ffmpeg doesn't use GPU

[FFmpeg-devel] [PATCH] avcodec/arbc: clear decoder state when seeking

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH] avcodec/arbc: clear decoder state when seeking

[FFmpeg-devel] configure: Fix decklink license dependency

Re: [FFmpeg-devel] configure: Fix decklink license dependency

Re: [FFmpeg-devel] [PATCH v2 09/11] vaapi_encode: Add support for VFR mode

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

Re: [FFmpeg-devel] [PATCH] avcodec/motion_est: remove duplicate function

Re: [FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

Re: [FFmpeg-devel] [PATCH v2 1/5] test/fate-run: duplicate pixfmts test when format is big-endian or native-endian

[FFmpeg-devel] [PATCH] avcodec/pgssubdec: Check for duplicate display segments

Re: [FFmpeg-devel] configure: Fix decklink license dependency

[FFmpeg-devel] [PATCH] avcodec/libx264: update notes to explain the scale chosen for ROI encoding

Re: [FFmpeg-devel] configure: Fix decklink license dependency

Re: [FFmpeg-devel] [PATCH]lavc/amrwbdec: Do not ignore NO_DATA frames

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

Re: [FFmpeg-devel] [PATCH] avformat/http: clarify that ffmpeg will attempt to add missing CRLF

Re: [FFmpeg-devel] [PATCH v2 2/5] swscale/swscale_unscaled: add missing gbrap10 on ff_get_unscaled_swscale

31 matches

Site Navigation

Mail list logo

Footer information