[FFmpeg-devel] [PATCH] lavf: add tranpose_opencl filter
Signed-off-by: Ruiling Song
---
configure | 1 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/opencl/transpose.cl | 35 +
libavfilter/opencl_source.h | 1 +
libavfilter/transpose.h | 34 +
libavfilter/vf_transpose.c| 14 +-
libavfilter/vf_transpose_opencl.c | 294 ++
8 files changed, 368 insertions(+), 13 deletions(-)
create mode 100644 libavfilter/opencl/transpose.cl
create mode 100644 libavfilter/transpose.h
create mode 100644 libavfilter/vf_transpose_opencl.c
diff --git a/configure b/configure
index b4f944c..dcb3f5f 100755
--- a/configure
+++ b/configure
@@ -3479,6 +3479,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
tonemap_opencl_filter_deps="opencl const_nan"
+transpose_opencl_filter_deps="opencl"
unsharp_opencl_filter_deps="opencl"
uspp_filter_deps="gpl avcodec"
vaguedenoiser_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1895fa2..6e26581 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -393,6 +393,7 @@ OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) +=
vf_tonemap_opencl.o colorspace.o
OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o
OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o cuda_check.o
+OBJS-$(CONFIG_TRANSPOSE_OPENCL_FILTER) += vf_transpose_opencl.o opencl.o
opencl/transpose.o
OBJS-$(CONFIG_TRIM_FILTER) += trim.o
OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o framesync.o
OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 837c99e..a600069 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -372,6 +372,7 @@ extern AVFilter ff_vf_tonemap_opencl;
extern AVFilter ff_vf_tpad;
extern AVFilter ff_vf_transpose;
extern AVFilter ff_vf_transpose_npp;
+extern AVFilter ff_vf_transpose_opencl;
extern AVFilter ff_vf_trim;
extern AVFilter ff_vf_unpremultiply;
extern AVFilter ff_vf_unsharp;
diff --git a/libavfilter/opencl/transpose.cl b/libavfilter/opencl/transpose.cl
new file mode 100644
index 000..e6388ab
--- /dev/null
+++ b/libavfilter/opencl/transpose.cl
@@ -0,0 +1,35 @@
+/*
+ * 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
+ */
+kernel void transpose(__write_only image2d_t dst,
+ __read_only image2d_t src,
+ int dir) {
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+ CLK_ADDRESS_CLAMP_TO_EDGE |
+ CLK_FILTER_NEAREST);
+
+int2 size = get_image_dim(dst);
+int x = get_global_id(0);
+int y = get_global_id(1);
+
+int xin = (dir & 2) ? (size.y - 1 - y) : y;
+int yin = (dir & 1) ? (size.x - 1 - x) : x;
+float4 data = read_imagef(src, sampler, (int2)(xin, yin));
+
+if (x < size.x && y < size.y)
+write_imagef(dst, (int2)(x, y), data);
+}
diff --git a/libavfilter/opencl_source.h b/libavfilter/opencl_source.h
index 2f67d89..4118138 100644
--- a/libavfilter/opencl_source.h
+++ b/libavfilter/opencl_source.h
@@ -25,6 +25,7 @@ extern const char *ff_opencl_source_convolution;
extern const char *ff_opencl_source_neighbor;
extern const char *ff_opencl_source_overlay;
extern const char *ff_opencl_source_tonemap;
+extern const char *ff_opencl_source_transpose;
extern const char *ff_opencl_source_unsharp;
#endif /* AVFILTER_OPENCL_SOURCE_H */
diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
new file mode 100644
index 000..da8b28e
--- /dev/null
+++ b/libavfilter/transpose.h
@@ -0,0 +1,34 @@
+/*
+ * 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
[FFmpeg-devel] [PATCH] avcodec/tiff: Fix integer overflows in left shift in init_image()
Fixes: left shift of 255 by 24 places cannot be represented in type 'int'
Fixes:
11377/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5694319101476864
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/tiff.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 6271c937c3..751f23ef33 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -706,7 +706,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
s->avctx->pix_fmt = s->palette_is_set ? AV_PIX_FMT_PAL8 :
AV_PIX_FMT_GRAY8;
break;
case 10081:
-switch (s->pattern[0] | (s->pattern[1] << 8) | (s->pattern[2] << 16) |
(s->pattern[3] << 24)) {
+switch (AV_RL32(s->pattern)) {
case 0x02010100:
s->avctx->pix_fmt = AV_PIX_FMT_BAYER_RGGB8;
break;
@@ -721,12 +721,12 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
break;
default:
av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
- s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
s->pattern[3] << 24);
+ AV_RL32(s->pattern));
return AVERROR_PATCHWELCOME;
}
break;
case 10121:
-switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
s->pattern[3] << 24) {
+switch (AV_RL32(s->pattern)) {
case 0x02010100:
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
AV_PIX_FMT_BAYER_RGGB16BE;
break;
@@ -741,12 +741,12 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
break;
default:
av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
- s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
s->pattern[3] << 24);
+ AV_RL32(s->pattern));
return AVERROR_PATCHWELCOME;
}
break;
case 10161:
-switch (s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
s->pattern[3] << 24) {
+switch (AV_RL32(s->pattern)) {
case 0x02010100:
s->avctx->pix_fmt = s->le ? AV_PIX_FMT_BAYER_RGGB16LE :
AV_PIX_FMT_BAYER_RGGB16BE;
break;
@@ -761,7 +761,7 @@ static int init_image(TiffContext *s, ThreadFrame *frame)
break;
default:
av_log(s->avctx, AV_LOG_ERROR, "Unsupported Bayer pattern: 0x%X\n",
- s->pattern[0] | s->pattern[1] << 8 | s->pattern[2] << 16 |
s->pattern[3] << 24);
+ AV_RL32(s->pattern));
return AVERROR_PATCHWELCOME;
}
break;
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize yuv2plane1_8
On Sat, Nov 24, 2018 at 11:33:01AM +0200, Lauri Kasanen wrote: > On Fri, 23 Nov 2018 23:01:02 +0100 > Michael Niedermayer wrote: > > > On Fri, Nov 23, 2018 at 10:38:13AM +0200, Lauri Kasanen wrote: > > > I mean, if my patch adds no failures, is that enough to apply it? > > > > yes that and the tests failing should still fail the same way with the > > same checksums > > This of course assumes noone finds an issue in the patch > > Okay, ran both with -k. No new failures, and fate-rv20-1239 failed with > the same checksums in both cases. That was the only failing test, did > not try with THREADS. ok, will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mem: Fix invalid use of av_alloc_size
On 2018-11-25 17:29, James Almer wrote: > On 11/25/2018 10:01 PM, Michael Niedermayer wrote: >> On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote: >>> The alloc_size attribute is valid only on functions that return a >>> pointer. GCC 9 (not yet released) warns about invalid usage: >>> >>> ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a >>> function returning int' [-Wattributes] >>> 342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, >>> size_t size); >>> | ^ >> >> Is the attribute also useless on all other compilers ? > > The attribute is only used when __GNUC__ is defined, so it should for > any such compiler (GCC and Clang). > > https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html > The Clang documentation does note a minor difference from GCC, but both GCC and Clang agree that it applies to functions that return a pointer. The size is the number of bytes allocated at that pointer. It doesn't support an indirect reference to the allocated memory; if it did it would likely need an additional parameter to indicate which argument was the indirect reference. https://clang.llvm.org/docs/AttributeReference.html#alloc-size - Mark ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresaw_enc : improvment (vendor and color properties, 4444Xq)
On Sat, Nov 24, 2018 at 11:04:38PM +0100, Martin Vignali wrote:
> proresenc_anatoliy.c | 49 ++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
> 44fe346a2be4d3d3ce2c903daf9cd599437627cc
> 0013-avcodec-prores_aw-only-set-color-prim-trc-space.patch
> From 119a246e570ff346490aef88710d8c8b4aae34e7 Mon Sep 17 00:00:00 2001
> From: Martin Vignali
> Date: Sat, 24 Nov 2018 22:48:08 +0100
> Subject: [PATCH 13/14] avcodec/prores_aw : only set color prim, trc, space
> values if supported
>
> set to unspecified if frame have another value
> ---
> libavcodec/proresenc_anatoliy.c | 49
> ++---
> 1 file changed, 46 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/proresenc_anatoliy.c b/libavcodec/proresenc_anatoliy.c
> index 8047f1c242..8098336b3b 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -656,6 +656,7 @@ static int prores_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> const AVFrame *pict, int *got_packet)
> {
> ProresContext *ctx = avctx->priv_data;
> +int color_primaries = 0, color_trc = 0, colorspace = 0;/* unspecified by
> default */
> int header_size = 148;
> uint8_t *buf;
> int pic_size, ret;
> @@ -686,9 +687,51 @@ static int prores_encode_frame(AVCodecContext *avctx,
> AVPacket *pkt,
> *buf++ = 0x82; // 422, not interlaced
> }
> *buf++ = 0; /* reserved */
> -*buf++ = pict->color_primaries;
> -*buf++ = pict->color_trc;
> -*buf++ = pict->colorspace;
> +
> +switch (pict->color_primaries) {
> +case AVCOL_PRI_RESERVED0:
> +case AVCOL_PRI_BT709:
> +case AVCOL_PRI_UNSPECIFIED:
> +case AVCOL_PRI_BT470BG:
> +case AVCOL_PRI_SMPTE170M:
> +case AVCOL_PRI_BT2020:
> +case AVCOL_PRI_SMPTE431:
> +case AVCOL_PRI_SMPTE432:
> +color_primaries = pict->color_primaries;
> +break;
> +default:
> +av_log(avctx, AV_LOG_DEBUG,
> + "Frame color primaries %d are not supported in prores frame.
> Set prores frame value to unspecified\n", pict->color_primaries);
> +break;
> +}
> +
> +switch (pict->color_trc) {
> +case AVCOL_TRC_RESERVED0:
> +case AVCOL_TRC_BT709:
> +case AVCOL_TRC_UNSPECIFIED:
> +color_trc = pict->color_trc;
> +break;
> +default:
> +av_log(avctx, AV_LOG_DEBUG,
> +"Frame color_trc %d are not supported in prores frame. Set
> prores frame value to unspecified\n", pict->color_trc);
> +break;
> +}
> +
> +switch (pict->colorspace) {
> +case AVCOL_SPC_BT709:
> +case AVCOL_SPC_UNSPECIFIED:
> +case AVCOL_SPC_SMPTE170M:
> +case AVCOL_SPC_BT2020_NCL:
> +colorspace = pict->colorspace;
> +break;
> +default:
> +av_log(avctx, AV_LOG_DEBUG,
> +"Frame colorspace %d are not supported in prores frame. Set
> prores frame value to unspecified\n", pict->colorspace);
> +break;
> +}
> +*buf++ = color_primaries;
> +*buf++ = color_trc;
> +*buf++ = colorspace;
we maybe should write a generic function that takes a list of supported types
and the undefined one and then does the check, debug print and all that
that could be used in other encoders too.
just an idea, that can be done later
the patch
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mem: Fix invalid use of av_alloc_size
On 11/25/2018 10:01 PM, Michael Niedermayer wrote: > On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote: >> The alloc_size attribute is valid only on functions that return a >> pointer. GCC 9 (not yet released) warns about invalid usage: >> >> ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a >> function returning int' [-Wattributes] >> 342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, >> size_t size); >> | ^ > > Is the attribute also useless on all other compilers ? The attribute is only used when __GNUC__ is defined, so it should for any such compiler (GCC and Clang). https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html > > thx > > [...] > > > > ___ > 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] avutil/mem: Fix invalid use of av_alloc_size
On Sat, Nov 24, 2018 at 01:02:02PM -0800, Mark Harris wrote: > The alloc_size attribute is valid only on functions that return a > pointer. GCC 9 (not yet released) warns about invalid usage: > > ./libavutil/mem.h:342:1: warning: 'alloc_size' attribute ignored on a > function returning int' [-Wattributes] > 342 | av_alloc_size(2, 3) int av_reallocp_array(void *ptr, size_t nmemb, > size_t size); > | ^ Is the attribute also useless on all other compilers ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
2018-11-25 16:17 GMT+01:00, Lauri Kasanen : > Hi, > > The lone power8 fate failing test seems like an aliasing issue. > I've isolated it into the attached standalone test case. Compiling it > with > gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize > -o test test.c > > reproduces on gcc 8.2.0, dropping the optimization level fixes it. This > was one of the "adding a printf made it work" things too. > > -Wstrict-aliasing=1 complains about the "register int *idataptr = > (int*)dataptr;" cast. If I put "typedef int __attribute__((may_alias)) > int_alias;" at the top and change the cast and type to int_alias, the > results become correct. Thank you for the analysis! Patch attached, Carl Eugen From e5403b832f2bcd360128d9986b602484e576c931 Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 26 Nov 2018 00:43:46 +0100 Subject: [PATCH] lavc/jrevdct: Avoid an aliasing violation. Fixes fate on different PowerPC systems with some compilers. Analyzed-by: Lauri Kasanen --- libavcodec/jrevdct.c | 17 + 1 file changed, 9 insertions(+), 8 deletions(-) diff --git a/libavcodec/jrevdct.c b/libavcodec/jrevdct.c index 3b15a52..c749468 100644 --- a/libavcodec/jrevdct.c +++ b/libavcodec/jrevdct.c @@ -63,6 +63,7 @@ */ #include "libavutil/common.h" +#include "libavutil/intreadwrite.h" #include "dct.h" #include "idctdsp.h" @@ -234,7 +235,7 @@ void ff_j_rev_dct(DCTBLOCK data) * row DCT calculations can be simplified this way. */ -register int *idataptr = (int*)dataptr; +register uint8_t *idataptr = (uint8_t*)dataptr; /* WARNING: we do the same permutation as MMX idct to simplify the video core */ @@ -254,10 +255,10 @@ void ff_j_rev_dct(DCTBLOCK data) int16_t dcval = (int16_t) (d0 * (1 << PASS1_BITS)); register int v = (dcval & 0x) | ((dcval * (1 << 16)) & 0x); - idataptr[0] = v; - idataptr[1] = v; - idataptr[2] = v; - idataptr[3] = v; + AV_WN32([ 0], v); + AV_WN32([ 4], v); + AV_WN32([ 8], v); + AV_WN32([12], v); } dataptr += DCTSIZE; /* advance pointer to next row */ @@ -974,7 +975,7 @@ void ff_j_rev_dct4(DCTBLOCK data) * row DCT calculations can be simplified this way. */ -register int *idataptr = (int*)dataptr; +register uint8_t *idataptr = (uint8_t*)dataptr; d0 = dataptr[0]; d2 = dataptr[1]; @@ -988,8 +989,8 @@ void ff_j_rev_dct4(DCTBLOCK data) int16_t dcval = (int16_t) (d0 << PASS1_BITS); register int v = (dcval & 0x) | ((dcval << 16) & 0x); - idataptr[0] = v; - idataptr[1] = v; + AV_WN32([0], v); + AV_WN32([4], v); } dataptr += DCTSTRIDE; /* advance pointer to next row */ -- 1.7.10.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avcodec/proresdec : add 12b decoding support
On Sat, Nov 24, 2018 at 08:59:50PM +0100, Martin Vignali wrote: > proresdec2.c |5 + > 1 file changed, 5 insertions(+) > 99ab52ec787a2de79da37daa0e17c7885fcb558f > 0010-avcodec-proresdec-align-height-buffer-to-16-avoid-se.patch > From 3c319ed4ef51e25bccfa0b4fc50edf0bcebf2f0a Mon Sep 17 00:00:00 2001 > From: Martin Vignali > Date: Sat, 17 Nov 2018 23:47:59 +0100 > Subject: [PATCH 10/11] avcodec/proresdec : align height buffer to 16 (avoid > segfault) > > --- > libavcodec/proresdec2.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c > index 8a537eed1a..f819f8db21 100644 > --- a/libavcodec/proresdec2.c > +++ b/libavcodec/proresdec2.c > @@ -750,6 +750,11 @@ static int decode_frame(AVCodecContext *avctx, void > *data, int *got_frame, > buf += frame_hdr_size; > buf_size -= frame_hdr_size; > > +/* align height to 16, to avoid segfault */ > +tframe.f->height = FFALIGN(avctx->height, 16); > +tframe.f->width = FFALIGN(avctx->width, 16); > +tframe.f->crop_bottom = tframe.f->height - avctx->height; > + > if ((ret = ff_thread_get_buffer(avctx, , 0)) < 0) > return ret; Why is this now needed but was not before ? Is avcodec_align_dimensions2() correct ? thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes
On 25/11/2018 22:22, Mark Thompson wrote:
> On 25/11/2018 21:28, Mironov, Mikhail wrote:
>> It seem that the failure is not in the new extension but before, in the
>> interop from D3D11 to OCL. It can happen in two cases: OCL device/context
>> are created without D3D11 device or format of the texture is not supported.
>> NV12 is supported. I went through the latest ffmpeg snapshot and found that
>> function opencl_enumerate_d3d11_devices() looks correct, pointer to the
>> function is set to OpenCLDeviceSelector::enumerate_devices member but I
>> cannot find a call to selector->enumerate_devices(). Instead
>> opencl_enumerate_devices() is called directly. So my guess is that created
>> OCL device is not created from D3D11.
>
> Hmm, right - patch just sent to fix the selection call.
>
> It doesn't actually make any difference to this case, though, since the
> filter made it choose the right device anyway and CL_CONTEXT_D3D11_DEVICE_KHR
> was always set when deriving from D3D11. (It could only have made a
> difference if there were other conflicting D3D11 devices it could have picked
> incorrectly.)
>
>> Just in case OCL device creation sample:
>> https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/public/samples/CPPSamples/common/DeviceOpenCL.cpp
>>
>> Regarding the new split extension: here is a working snippet:
>> cl_mem clImage2D = 0;
>> cl_mem clImages[AMF_SURFACE_MAX_PLANES];
>> // index can be not 0 if texture is allocated as an array.
>> clImage2D = clCreateFromD3D11Texture2DKHR(m_clContext, memflags, pTexture,
>> index, );
>
> Where is the comment about index being nonzero coming from there? Other
> callers to this definitely start from a zero index. (I tried adding one to
> my index values but it didn't change the result.)
Urgh, sorry - ignore that question, I misread "can be not 0" as "cannot be 0".
>>
>> for(int i = 0; i < planesNumber; i++)
>> {
>> clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D,
>> (cl_uint)i, );
>>
>> }
>> // don’t forget to release clImages[i] and clImage2D
>
> Otherwise, that agrees with how I read the extension document.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes
On 25/11/2018 21:28, Mironov, Mikhail wrote:
> It seem that the failure is not in the new extension but before, in the
> interop from D3D11 to OCL. It can happen in two cases: OCL device/context are
> created without D3D11 device or format of the texture is not supported. NV12
> is supported. I went through the latest ffmpeg snapshot and found that
> function opencl_enumerate_d3d11_devices() looks correct, pointer to the
> function is set to OpenCLDeviceSelector::enumerate_devices member but I
> cannot find a call to selector->enumerate_devices(). Instead
> opencl_enumerate_devices() is called directly. So my guess is that created
> OCL device is not created from D3D11.
Hmm, right - patch just sent to fix the selection call.
It doesn't actually make any difference to this case, though, since the filter
made it choose the right device anyway and CL_CONTEXT_D3D11_DEVICE_KHR was
always set when deriving from D3D11. (It could only have made a difference if
there were other conflicting D3D11 devices it could have picked incorrectly.)
> Just in case OCL device creation sample:
> https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/public/samples/CPPSamples/common/DeviceOpenCL.cpp
>
> Regarding the new split extension: here is a working snippet:
> cl_mem clImage2D = 0;
> cl_mem clImages[AMF_SURFACE_MAX_PLANES];
> // index can be not 0 if texture is allocated as an array.
> clImage2D = clCreateFromD3D11Texture2DKHR(m_clContext, memflags, pTexture,
> index, );
Where is the comment about index being nonzero coming from there? Other
callers to this definitely start from a zero index. (I tried adding one to my
index values but it didn't change the result.)
>
> for(int i = 0; i < planesNumber; i++)
> {
> clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D,
> (cl_uint)i, );
>
> }
> // don’t forget to release clImages[i] and clImage2D
Otherwise, that agrees with how I read the extension document.
Thanks,
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] hwcontext_opencl: Use correct function to enumerate devices
--- libavutil/hwcontext_opencl.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c index e6cef74269..6a26354c87 100644 --- a/libavutil/hwcontext_opencl.c +++ b/libavutil/hwcontext_opencl.c @@ -542,9 +542,9 @@ static int opencl_device_create_internal(AVHWDeviceContext *hwdev, continue; } -err = opencl_enumerate_devices(hwdev, platforms[p], platform_name, - _devices, , - selector->context); +err = selector->enumerate_devices(hwdev, platforms[p], platform_name, + _devices, , + selector->context); if (err < 0) continue; -- 2.19.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cbs: Add function to make content of a unit writable
2018-11-25 22:44 GMT+01:00, Andreas Rheinhardt : > Carl Eugen Hoyos: >> 2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt >> : >> >>> +.make_writable = NULL, >> >> Why do you think these are needed? >> > It's not needed. If left out, .make_writable will be implicitly initialized > to a NULL pointer because the various ff_cbs_type_xyz all have static > storage duration. But I nevertheless thought that it is nicer to make the > initialization explicit, because then you actually see all the members of > each CodedBitstreamType. Please leave it out like in hundreds of existing cases. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cbs: Add function to make content of a unit writable
Carl Eugen Hoyos: > 2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt > : > >> +.make_writable = NULL, > > Why do you think these are needed? > > Carl Eugen It's not needed. If left out, .make_writable will be implicitly initialized to a NULL pointer because the various ff_cbs_type_xyz all have static storage duration. But I nevertheless thought that it is nicer to make the initialization explicit, because then you actually see all the members of each CodedBitstreamType. Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes
It seem that the failure is not in the new extension but before, in the interop
from D3D11 to OCL. It can happen in two cases: OCL device/context are created
without D3D11 device or format of the texture is not supported. NV12 is
supported. I went through the latest ffmpeg snapshot and found that function
opencl_enumerate_d3d11_devices() looks correct, pointer to the function is set
to OpenCLDeviceSelector::enumerate_devices member but I cannot find a call to
selector->enumerate_devices(). Instead opencl_enumerate_devices() is called
directly. So my guess is that created OCL device is not created from D3D11.
Just in case OCL device creation sample:
https://github.com/GPUOpen-LibrariesAndSDKs/AMF/blob/master/amf/public/samples/CPPSamples/common/DeviceOpenCL.cpp
Regarding the new split extension: here is a working snippet:
cl_mem clImage2D = 0;
cl_mem clImages[AMF_SURFACE_MAX_PLANES];
// index can be not 0 if texture is allocated as an array.
clImage2D = clCreateFromD3D11Texture2DKHR(m_clContext, memflags, pTexture,
index, );
for(int i = 0; i < planesNumber; i++)
{
clImages[i] = clGetPlaneFromImageAMD(m_clContext, clImage2D,
(cl_uint)i, );
}
// don’t forget to release clImages[i] and clImage2D
Regards,
Mikhail
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Mark Thompson
> Sent: November 25, 2018 2:35 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension
> for NV12 and P010 textures - split planes
>
> On 24/05/2018 15:26, Mironov, Mikhail wrote:
> > AMD has published OpenCL extension which allows split D3D11 texture
> interoped as a single 2D image into two 2D images representing Y and UV
> planes.
> >
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar
> _y
> > uv.txt
>
> I had a go at implementing this now that it is actually visible in released
> drivers, but I can't get it to work.
>
> Patch trying to implement it is below. It finds the extension and the new
> function correctly, but I'm stuck on the creation of the whole-texture image
> with clCreateFromD3D11Texture2DKHR(). The error returned is
> CL_INVALID_D3D11_RESOURCE_KHR (-1007), but as far as I can tell none of
> the documented failure cases which would return that error code apply.
>
> $ ./ffmpeg_g.exe -report -v debug -y -hwaccel d3d11va -hwaccel_device 0 -
> hwaccel_output_format d3d11 -i input.mp4 -an -vf
> "hwmap=derive_device=opencl:mode=read,unsharp_opencl,hwdownload,fo
> rmat=nv12" -f null - ...
> [AVHWDeviceContext @ 01c0de80] Using device 1002:665f (AMD
> Radeon (TM) R7 360 Series).
> ...
> [h264 @ 0284adc0] Format d3d11 chosen by get_format().
> ...
> [Parsed_hwmap_0 @ 02a2be00] Configure hwmap d3d11 ->
> opencl.
> [AVHWDeviceContext @ 0d328500] 2 OpenCL platforms found.
> [AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on
> platform "Intel(R) OpenCL".
> [AVHWDeviceContext @ 0d328500] Device Intel(R) Core(TM) i3-
> 6300 CPU @ 3.80GHz skipped (not GPU).
> [AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on
> platform "AMD Accelerated Parallel Processing".
> [AVHWDeviceContext @ 0d328500] 1.0: AMD Accelerated Parallel
> Processing / Bonaire [AVHWDeviceContext @ 0d328500] DXVA2 to
> OpenCL mapping function found (clCreateFromDX9MediaSurfaceKHR).
> [AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL acquire
> function found (clEnqueueAcquireDX9MediaSurfacesKHR).
> [AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL release
> function found (clEnqueueReleaseDX9MediaSurfacesKHR).
> [AVHWDeviceContext @ 0d328500] cl_khr_d3d11_sharing found as
> platform extension.
> [AVHWDeviceContext @ 0d328500] cl_amd_planar_yuv found as
> device extension.
> [AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping
> function found (clCreateFromD3D11Texture2DKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 in OpenCL acquire
> function found (clEnqueueAcquireD3D11ObjectsKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 in OpenCL release
> function found (clEnqueueReleaseD3D11ObjectsKHR).
> [AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping on
> AMD function found (clGetPlaneFromImageAMD).
> [AVHWFramesContext @ 02c13180] Failed to create CL image from
> D3D texture index 0: -1007.
> [Parsed_hwmap_0 @ 02a2be00] Failed to create derived frames
> context: -5.
> [Parsed_hwmap_0 @ 02a2be00] Failed to configure output pad on
> Parsed_hwmap_0
>
>
> Are there any examples of using this extension that I could compare with?
> Alternatively, is the source code for the CL driver available somewhere so
> that I can work out what that error actually means?
>
> Thanks,
>
> - Mark
>
>
> From 25fb98f021b1347394d56ecf4781466096616542 Mon Sep 17 00:00:00
> 2001
> From: Mark Thompson
> Date: Sun, 25 Nov 2018 16:59:24 +
> Subject: [PATCH] hwcontext_opencl: Add support for D3D11 to OpenCL
Re: [FFmpeg-devel] fate/prores metadata : Make output bit exact
2018-11-24 18:44 GMT+01:00, Martin Vignali : > Patch in attach fix prores-metadata test > add bitexact mode, to avoid to write encoder in target mov Patch applied. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH V4 5/6] lavf/isom: use side data to save max bit rate for esds box
On Sat, Nov 24, 2018 at 11:31:16AM +0800, Jun Zhao wrote:
> Use AV_PKT_DATA_CPB_PROPERTIES to save max bit rate for esds box,
> and update fate at the same time.
>
> Signed-off-by: Jun Zhao
> ---
> libavformat/isom.c | 19 ---
> tests/ref/fate/adtstoasc_ticket3715 |2 +-
> tests/ref/fate/copy-psp |4 ++--
> tests/ref/fate/gaplessenc-itunes-to-ipod-aac | 10 ++
> tests/ref/fate/gaplessenc-pcm-to-mov-aac | 10 ++
> tests/ref/fate/gaplessinfo-itunes1 | 10 ++
> tests/ref/fate/gaplessinfo-itunes2 | 10 ++
> tests/ref/fate/mov-mp3-demux |2 +-
> 8 files changed, 40 insertions(+), 27 deletions(-)
>
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index ca9d22e..1780490 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -508,18 +508,23 @@ int ff_mp4_read_dec_config_descr(AVFormatContext *fc,
> AVStream *st, AVIOContext
> int len, tag;
> int ret;
> int object_type_id = avio_r8(pb);
> +AVCPBProperties *props = NULL;
> +
> avio_r8(pb); /* stream type */
> avio_rb24(pb); /* buffer size db */
>
> v = avio_rb32(pb);
>
> -// TODO: fix this with codecpar
> -#if FF_API_LAVF_AVCTX
> -FF_DISABLE_DEPRECATION_WARNINGS
> -if (v < INT32_MAX)
> -st->codec->rc_max_rate = v;
> -FF_ENABLE_DEPRECATION_WARNINGS
> -#endif
> +if (v < INT32_MAX) {
> +props = (AVCPBProperties *)av_stream_new_side_data(
> +st,
> +AV_PKT_DATA_CPB_PROPERTIES,
> +sizeof(*props));
av_cpb_properties_alloc()
> +if (!props)
> +return AVERROR(ENOMEM);
> +memset(props, 0, sizeof(*props));
code should avoid directly using the structure size, sometines these structs
can end up having fields added at their end.
For example the INT32_MAX check here shows that the struct is broken and
a 64bit field should have been used so a change will be needed eventually
> +props->max_bitrate = v; /* max bitrate */
This patch is possibly the first that sets AV_PKT_DATA_CPB_PROPERTIES
from a demuxer.
So this will require some things to be checked.
Muxers store the AV_PKT_DATA_CPB_PROPERTIES and demuxers read them
that is fine but not together because applications can copy this even when
using an encoder in between.
I think there is no clean way to do this currently, but someone please
correct me if there is ...
applications need to know which side data types depend on the encoder,
which on the resolution, sample rate, input stream semantically, and so on
So that an applications can discard side data that has become incorrect from
some changes.
Some of the side data that we have is encoder specific like the bitrate/VBV
parameters here while others are pure input describing.
The idea that all this is uneeded because side data should just be passed
through libavfilter also does not work as an application can use its own
filter framework. It really seems to need to know what to do with newly added
types.
If the side data from the demuxer with an encoder ends up actually written
that would result in broken and invalid files being produced. So this needs
to be looked at carefully, we do not want to create files with incorrect
VBV parameters.
also more problems can possibly result from both a demuxer and an encoder
producing this side data.
Its important here to also understand that the applications which calls the
demuxer, muxer and encoder may have been written at a time before a specific
type of side data existed. So a solution has to not depend on an application
containing code specific to each side data type. As this would not work very
well when in the future new types are added.
thx
[...]
--
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] h264_redundant_pps: Make it reference-compatible
Since c6a63e11092c975b89d824f08682fe31948d3686, the parameter sets
modified as content of PPS units were references shared with the
CodedBitstreamH264Context, so modifying them alters the parsing process
of future access units which meant that frames often got discarded
because invalid values were parsed. This patch makes h264_redundant_pps
compatible with the reality of reference-counted parameter sets.
Signed-off-by: Andreas Rheinhardt
---
This version is compatible with the new make_unit_writable function.
libavcodec/h264_redundant_pps_bsf.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavcodec/h264_redundant_pps_bsf.c
b/libavcodec/h264_redundant_pps_bsf.c
index 0b7888c97e..c484357942 100644
--- a/libavcodec/h264_redundant_pps_bsf.c
+++ b/libavcodec/h264_redundant_pps_bsf.c
@@ -40,8 +40,17 @@ typedef struct H264RedundantPPSContext {
static int h264_redundant_pps_fixup_pps(H264RedundantPPSContext *ctx,
-H264RawPPS *pps)
+CodedBitstreamUnit *unit)
{
+H264RawPPS *pps;
+int err;
+// The changes we are about to perform affect the parsing process,
+// so we must make sure that the PPS is writable, otherwise the
+// parsing of future slices will be incorrect and even raise errors.
+if ((err = ff_cbs_make_unit_writable(ctx->input, unit, NULL)) < 0)
+return err;
+pps = unit->content;
+
// Record the current value of pic_init_qp in order to fix up
// following slices, then overwrite with the global value.
ctx->current_pic_init_qp = pps->pic_init_qp_minus26 + 26;
@@ -89,7 +98,7 @@ static int h264_redundant_pps_filter(AVBSFContext *bsf,
AVPacket *out)
if (nal->type == H264_NAL_SPS)
au_has_sps = 1;
if (nal->type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, nal->content);
+err = h264_redundant_pps_fixup_pps(ctx, nal);
if (err < 0)
goto fail;
if (!au_has_sps) {
@@ -151,7 +160,7 @@ static int h264_redundant_pps_init(AVBSFContext *bsf)
for (i = 0; i < au->nb_units; i++) {
if (au->units[i].type == H264_NAL_PPS) {
-err = h264_redundant_pps_fixup_pps(ctx, au->units[i].content);
+err = h264_redundant_pps_fixup_pps(ctx, >units[i]);
if (err < 0)
goto fail;
}
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] cbs: Add function to make content of a unit writable
2018-11-25 22:05 GMT+01:00, Andreas Rheinhardt : > +.make_writable = NULL, Why do you think these are needed? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] cbs: Add function to make content of a unit writable
This will enable us to change e.g. the parameter sets of H.2645 in ways
that would change the parsing process of future units. An example of
this is the h264_redundant_pps bsf.
The actual implementation of the underlying codec-dependent
make_writable functions is not contained in this commit.
Signed-off-by: Andreas Rheinhardt
---
This is a slight extension to my previous patch. In lots of cases where
this function will be applied, the user will already have a pointer to
the unit's content and this addition updates the pointer automatically.
libavcodec/cbs.c | 21 +
libavcodec/cbs.h | 9 +
libavcodec/cbs_av1.c | 1 +
libavcodec/cbs_h2645.c| 2 ++
libavcodec/cbs_internal.h | 4
libavcodec/cbs_jpeg.c | 1 +
libavcodec/cbs_mpeg2.c| 1 +
libavcodec/cbs_vp9.c | 1 +
8 files changed, 40 insertions(+)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index ecbf57c293..cb2ee3a769 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -665,3 +665,24 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
return 0;
}
+
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
+ void** content)
+{
+if (unit->content && (!unit->content_ref ||
+ !av_buffer_is_writable(unit->content_ref))) {
+int err;
+if (!ctx->codec->make_writable)
+return AVERROR_PATCHWELCOME;
+
+err = ctx->codec->make_writable(ctx, unit);
+if (err < 0)
+return err;
+
+if (content)
+*content = unit->content;
+}
+
+return 0;
+}
diff --git a/libavcodec/cbs.h b/libavcodec/cbs.h
index 53ac360bb1..9bdc6aa5fd 100644
--- a/libavcodec/cbs.h
+++ b/libavcodec/cbs.h
@@ -352,5 +352,14 @@ int ff_cbs_delete_unit(CodedBitstreamContext *ctx,
CodedBitstreamFragment *frag,
int position);
+/**
+ * Make the content of a unit writable.
+ *
+ * If content is supplied, *content will point to the unit's content on
success.
+ */
+int ff_cbs_make_unit_writable(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
+ void **content);
+
#endif /* AVCODEC_CBS_H */
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index e02bc7027a..ce8ee3faaa 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1305,6 +1305,7 @@ const CodedBitstreamType ff_cbs_type_av1 = {
.split_fragment= _av1_split_fragment,
.read_unit = _av1_read_unit,
+.make_writable = NULL,
.write_unit= _av1_write_unit,
.assemble_fragment = _av1_assemble_fragment,
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 666970ed03..7296c4cf29 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1545,6 +1545,7 @@ const CodedBitstreamType ff_cbs_type_h264 = {
.split_fragment= _h2645_split_fragment,
.read_unit = _h264_read_nal_unit,
+.make_writable = NULL,
.write_unit= _h2645_write_nal_unit,
.assemble_fragment = _h2645_assemble_fragment,
@@ -1558,6 +1559,7 @@ const CodedBitstreamType ff_cbs_type_h265 = {
.split_fragment= _h2645_split_fragment,
.read_unit = _h265_read_nal_unit,
+.make_writable = NULL,
.write_unit= _h2645_write_nal_unit,
.assemble_fragment = _h2645_assemble_fragment,
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 53f2e5d187..62a836af90 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -44,6 +44,10 @@ typedef struct CodedBitstreamType {
int (*read_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
+// Make a unit's content writable.
+int (*make_writable)(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit);
+
// Write the unit->data bitstream from unit->content.
int (*write_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index 5a72f0e2e7..f3706e7575 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -513,6 +513,7 @@ const CodedBitstreamType ff_cbs_type_jpeg = {
.split_fragment= _jpeg_split_fragment,
.read_unit = _jpeg_read_unit,
+.make_writable = NULL,
.write_unit= _jpeg_write_unit,
.assemble_fragment = _jpeg_assemble_fragment,
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 8b8b266563..3e6a109550 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -414,6 +414,7 @@ const CodedBitstreamType ff_cbs_type_mpeg2 = {
.split_fragment= _mpeg2_split_fragment,
.read_unit = _mpeg2_read_unit,
+.make_writable = NULL,
.write_unit= _mpeg2_write_unit,
Re: [FFmpeg-devel] [PATCH 11/12] lavf/sccdec: fix timestamps and demux one eai608 frame at a time
On 7/4/18, Baptiste Coudurier wrote: > --- > libavformat/sccdec.c | 100 --- > 1 file changed, 56 insertions(+), 44 deletions(-) > Will those scc patches be applied? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [INFO]AMD D3D11 to OpenCL interop extension for NV12 and P010 textures - split planes
On 24/05/2018 15:26, Mironov, Mikhail wrote:
> AMD has published OpenCL extension which allows split D3D11 texture interoped
> as a single 2D image into two 2D images representing Y and UV planes.
> https://www.khronos.org/registry/OpenCL/extensions/amd/cl_amd_planar_yuv.txt
I had a go at implementing this now that it is actually visible in released
drivers, but I can't get it to work.
Patch trying to implement it is below. It finds the extension and the new
function correctly, but I'm stuck on the creation of the whole-texture image
with clCreateFromD3D11Texture2DKHR(). The error returned is
CL_INVALID_D3D11_RESOURCE_KHR (-1007), but as far as I can tell none of the
documented failure cases which would return that error code apply.
$ ./ffmpeg_g.exe -report -v debug -y -hwaccel d3d11va -hwaccel_device 0
-hwaccel_output_format d3d11 -i input.mp4 -an -vf
"hwmap=derive_device=opencl:mode=read,unsharp_opencl,hwdownload,format=nv12" -f
null -
...
[AVHWDeviceContext @ 01c0de80] Using device 1002:665f (AMD Radeon (TM)
R7 360 Series).
...
[h264 @ 0284adc0] Format d3d11 chosen by get_format().
...
[Parsed_hwmap_0 @ 02a2be00] Configure hwmap d3d11 -> opencl.
[AVHWDeviceContext @ 0d328500] 2 OpenCL platforms found.
[AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on platform
"Intel(R) OpenCL".
[AVHWDeviceContext @ 0d328500] Device Intel(R) Core(TM) i3-6300 CPU @
3.80GHz skipped (not GPU).
[AVHWDeviceContext @ 0d328500] 1 OpenCL devices found on platform "AMD
Accelerated Parallel Processing".
[AVHWDeviceContext @ 0d328500] 1.0: AMD Accelerated Parallel Processing
/ Bonaire
[AVHWDeviceContext @ 0d328500] DXVA2 to OpenCL mapping function found
(clCreateFromDX9MediaSurfaceKHR).
[AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL acquire function found
(clEnqueueAcquireDX9MediaSurfacesKHR).
[AVHWDeviceContext @ 0d328500] DXVA2 in OpenCL release function found
(clEnqueueReleaseDX9MediaSurfacesKHR).
[AVHWDeviceContext @ 0d328500] cl_khr_d3d11_sharing found as platform
extension.
[AVHWDeviceContext @ 0d328500] cl_amd_planar_yuv found as device
extension.
[AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping function found
(clCreateFromD3D11Texture2DKHR).
[AVHWDeviceContext @ 0d328500] D3D11 in OpenCL acquire function found
(clEnqueueAcquireD3D11ObjectsKHR).
[AVHWDeviceContext @ 0d328500] D3D11 in OpenCL release function found
(clEnqueueReleaseD3D11ObjectsKHR).
[AVHWDeviceContext @ 0d328500] D3D11 to OpenCL mapping on AMD function
found (clGetPlaneFromImageAMD).
[AVHWFramesContext @ 02c13180] Failed to create CL image from D3D
texture index 0: -1007.
[Parsed_hwmap_0 @ 02a2be00] Failed to create derived frames context: -5.
[Parsed_hwmap_0 @ 02a2be00] Failed to configure output pad on
Parsed_hwmap_0
Are there any examples of using this extension that I could compare with?
Alternatively, is the source code for the CL driver available somewhere so that
I can work out what that error actually means?
Thanks,
- Mark
From 25fb98f021b1347394d56ecf4781466096616542 Mon Sep 17 00:00:00 2001
From: Mark Thompson
Date: Sun, 25 Nov 2018 16:59:24 +
Subject: [PATCH] hwcontext_opencl: Add support for D3D11 to OpenCL mapping on
AMD
Uses cl_amd_planar_yuv.
---
libavutil/hwcontext_opencl.c | 106 ---
1 file changed, 86 insertions(+), 20 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 728877553f..c745b91775 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -64,6 +64,12 @@
#if HAVE_OPENCL_D3D11
#include
#include "hwcontext_d3d11va.h"
+
+// From cl_amd_planar_yuv; unfortunately no header is provided.
+typedef cl_mem (*clGetPlaneFromImageAMD_fn)(cl_context context,
+cl_mem mem,
+cl_uintplane,
+cl_int*errcode_ret);
#endif
#if HAVE_OPENCL_DRM_ARM
@@ -113,12 +119,17 @@ typedef struct OpenCLDeviceContext {
#if HAVE_OPENCL_D3D11
int d3d11_mapping_usable;
+int d3d11_map_amd;
+int d3d11_map_intel;
+
clCreateFromD3D11Texture2DKHR_fn
clCreateFromD3D11Texture2DKHR;
clEnqueueAcquireD3D11ObjectsKHR_fn
clEnqueueAcquireD3D11ObjectsKHR;
clEnqueueReleaseD3D11ObjectsKHR_fn
clEnqueueReleaseD3D11ObjectsKHR;
+clGetPlaneFromImageAMD_fn
+clGetPlaneFromImageAMD;
#endif
#if HAVE_OPENCL_DRM_ARM
@@ -817,17 +828,25 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
#if HAVE_OPENCL_D3D11
{
const char *d3d11_ext = "cl_khr_d3d11_sharing";
-const char *nv12_ext = "cl_intel_d3d11_nv12_media_sharing";
+const char *amd_ext = "cl_amd_planar_yuv";
+const char *intel_ext =
[FFmpeg-devel] [PATCH] hwcontext_opencl: Only release command queue if it exists
If the frames context creation fails then the command queue reference
need not exist when uninit is called.
---
libavutil/hwcontext_opencl.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index c745b91775..e6cef74269 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -1750,10 +1750,13 @@ static void opencl_frames_uninit(AVHWFramesContext
*hwfc)
av_freep(>mapped_frames);
#endif
-cle = clReleaseCommandQueue(priv->command_queue);
-if (cle != CL_SUCCESS) {
-av_log(hwfc, AV_LOG_ERROR, "Failed to release frame "
- "command queue: %d.\n", cle);
+if (priv->command_queue) {
+cle = clReleaseCommandQueue(priv->command_queue);
+if (cle != CL_SUCCESS) {
+av_log(hwfc, AV_LOG_ERROR, "Failed to release frame "
+ "command queue: %d.\n", cle);
+}
+priv->command_queue = NULL;
}
}
--
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
On Sun, 25 Nov 2018 17:17:58 +0200 Lauri Kasanen wrote: > This code would probably crash on systems where unaligned access is > prohibited, I think the incoming block is just 16-bit aligned. I see the block comes from aligned malloc, so scratch that part, it's at least 128-bit aligned. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] fate-rv20-1239 failure on power8, aliasing bug
Hi, The lone power8 fate failing test seems like an aliasing issue. I've isolated it into the attached standalone test case. Compiling it with gcc -std=c11 -maltivec -mabi=altivec -mvsx -O3 -fno-tree-vectorize -o test test.c reproduces on gcc 8.2.0, dropping the optimization level fixes it. This was one of the "adding a printf made it work" things too. -Wstrict-aliasing=1 complains about the "register int *idataptr = (int*)dataptr;" cast. If I put "typedef int __attribute__((may_alias)) int_alias;" at the top and change the cast and type to int_alias, the results become correct. This code would probably crash on systems where unaligned access is prohibited, I think the incoming block is just 16-bit aligned. How do you prefer to fix alignment/aliasing issues? - Lauri test.c Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.
On 24/11/18 01:44, Timo Rothenpieler wrote:
> ---
> libavcodec/decode.c| 9 +
> libavcodec/options_table.h | 2 +-
> 2 files changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c89c77c43a..08ae8788a2 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1256,10 +1256,11 @@ int avcodec_get_hw_frames_parameters(AVCodecContext
> *avctx,
> AVHWFramesContext *frames_ctx = (AVHWFramesContext*)frames_ref->data;
>
> if (frames_ctx->initial_pool_size) {
> -// If the user has requested that extra output surfaces be
> -// available then add them here.
> -if (avctx->extra_hw_frames > 0)
> -frames_ctx->initial_pool_size += avctx->extra_hw_frames;
> +// If the user has requested extra/fewer output surfaces be
> +// available then add/substract them here.
> +frames_ctx->initial_pool_size += avctx->extra_hw_frames;
> +if (avctx->extra_hw_frames < 0)
> +av_log(avctx, AV_LOG_WARNING, "Decreasing hwaccel frame pool
> size!\n");
>
> // If frame threading is enabled then an extra surface per thread
> // is also required.
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 099261e168..af0ab1cfe0 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -478,7 +478,7 @@ static const AVOption avcodec_options[] = {
> {"ignore_level", "ignore level even if the codec level used is unknown or
> higher than the maximum supported level reported by the hardware driver", 0,
> AV_OPT_TYPE_CONST, { .i64 = AV_HWACCEL_FLAG_IGNORE_LEVEL }, INT_MIN, INT_MAX,
> V | D, "hwaccel_flags" },
> {"allow_high_depth", "allow to output YUV pixel formats with a different
> chroma sampling than 4:2:0 and/or other than 8 bits per component", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_HIGH_DEPTH }, INT_MIN,
> INT_MAX, V | D, "hwaccel_flags"},
> {"allow_profile_mismatch", "attempt to decode anyway if HW accelerated
> decoder's supported profiles do not exactly match the stream", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_HWACCEL_FLAG_ALLOW_PROFILE_MISMATCH }, INT_MIN,
> INT_MAX, V | D, "hwaccel_flags"},
> -{"extra_hw_frames", "Number of extra hardware frames to allocate for the
> user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
> V|D },
> +{"extra_hw_frames", "Number of extra hardware frames to allocate for the
> user, negative values are supported at own risk", OFFSET(extra_hw_frames),
> AV_OPT_TYPE_INT, { .i64 = 0 }, INT_MIN, INT_MAX, V|D },
> {NULL},
> };
I see what you're trying to do here, but I'm not sure that overloading this
option is the best way to achieve it. This option has a specific meaning in
terms of the consumer of the frames, and is intended to be negotiated (any
consumers of hardware frames should declare how many they will hold onto at
most in a given configuration), but since that is very much
configuration-dependent it hasn't yet been done. Setting it to, for example,
-3 ends up saying "I want the frame pool to be large enough for the consumer to
be able to hold onto at most -2 frames at any given time", which is nonsensical
in the meaning of the particular option.
Presumably the case you're actually imagining wanting this option is to reduce
memory use when a stream doesn't actually use the maximum number of reference
frames - given that this is generally signalled in the stream, can you instead
propagate the real number of reference frames into the allocation so that it
uses the correct number rather than the maximum? Alternatively, if you have
some particular program in mind then it could just use hw_frames_ctx rather
than hw_device_ctx and do this allocation itself.
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/ac3dec: always skip junk bytes before sync bytes
Fixes #7278.
Signed-off-by: Paul B Mahol
---
libavcodec/ac3dec.c | 19 ---
libavformat/ac3dec.c | 2 +-
2 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 43b22b7654..90e4dc8a1f 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1467,7 +1467,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
int buf_size, full_buf_size = avpkt->size;
AC3DecodeContext *s = avctx->priv_data;
int blk, ch, err, offset, ret;
-int got_independent_frame = 0;
+int skip = 0, got_independent_frame = 0;
const uint8_t *channel_map;
uint8_t extended_channel_map[EAC3_MAX_CHANNELS];
const SHORTFLOAT *output[AC3_MAX_CHANNELS];
@@ -1477,6 +1477,14 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
s->superframe_size = 0;
buf_size = full_buf_size;
+while (buf_size > 2) {
+if (AV_RB16(buf) != 0x770B && AV_RL16(buf) != 0x770B) {
+buf += 1;
+buf_size -= 1;
+continue;
+}
+break;
+}
/* copy input buffer to decoder context to avoid reading past the end
of the buffer, which can be caused by a damaged input stream. */
if (buf_size >= 2 && AV_RB16(buf) == 0x770B) {
@@ -1637,6 +1645,10 @@ dependent_frame:
AC3HeaderInfo hdr;
int err;
+if (buf_size - s->frame_size <= 16)
+skip = buf_size - s->frame_size;
+goto skip;
+
if ((ret = init_get_bits8(>gbc, buf + s->frame_size, buf_size -
s->frame_size)) < 0)
return ret;
@@ -1657,6 +1669,7 @@ dependent_frame:
}
}
}
+skip:
frame->decode_error_flags = err ? FF_DECODE_ERROR_INVALID_BITSTREAM : 0;
@@ -1796,9 +1809,9 @@ dependent_frame:
*got_frame_ptr = 1;
if (!s->superframe_size)
-return FFMIN(full_buf_size, s->frame_size);
+return FFMIN(full_buf_size, s->frame_size + skip);
-return FFMIN(full_buf_size, s->superframe_size);
+return FFMIN(full_buf_size, s->superframe_size + skip);
}
/**
diff --git a/libavformat/ac3dec.c b/libavformat/ac3dec.c
index 6f423ff7eb..2718061bdc 100644
--- a/libavformat/ac3dec.c
+++ b/libavformat/ac3dec.c
@@ -47,7 +47,7 @@ static int ac3_eac3_probe(AVProbeData *p, enum AVCodecID
expected_codec_id)
uint16_t frame_size;
int i, ret;
-if(!memcmp(buf2, "\x1\x10\0\0\0\0\0\0", 8)) {
+if(!memcmp(buf2, "\x1\x10", 2)) {
if (buf2 + 16 > end)
break;
buf2+=16;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey
On Sat, Nov 24, 2018 at 2:23 PM René J.V. Bertin wrote: > I have had my ML subscriptions set to not receive emails for a few years now. > So when I got the invitation to vote (which I don't consider Spam btw) my > first reflex was to confirm that I do not have any current issues with > perceived hostility in the community. > > Then, when I checked the few replies to this thread before replying myself to > explain my vote (and suggest that maybe this survey shouldn't have gone out > to inactive members) I wondered if I shouldn't have voted yes... To be honest, I was surprised the survey was a single yes/no selection. I voted "no", but I'd have loved to be able to say "no, but …" and provide some more context. The way the survey is set up, I wouldn't be surprised if you get a lot of "no" answers by people who had a first-hand experience with hostility in this project, but would not want to generalize. That being said, thanks for initiating the discussion, Thilo. Werner ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/decode: allow users to shrink the hw frames pool size, if they so desire.
On Sat, Nov 24, 2018 at 02:44:45 +0100, Timo Rothenpieler wrote:
> +// available then add/substract them here.
^ nit: subtract
> -{"extra_hw_frames", "Number of extra hardware frames to allocate for the
> user", OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX,
> V|D },
> +{"extra_hw_frames", "Number of extra hardware frames to allocate for the
> user, negative values are supported at own risk", OFFSET(extra_hw_frames),
> AV_OPT_TYPE_INT, { .i64 = 0 }, INT_MIN, INT_MAX, V|D },
"at own risk" sounds hazy, but I guess the consequences can't be
explained here.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromashift: Fix mixed declaration and code
On 11/25/18, Mark Harris wrote: > --- > libavfilter/vf_chromashift.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavfilter/vf_chromashift.c b/libavfilter/vf_chromashift.c > index 068c3c1b68..d073256b99 100644 > --- a/libavfilter/vf_chromashift.c > +++ b/libavfilter/vf_chromashift.c > @@ -76,13 +76,14 @@ static int query_formats(AVFilterContext *ctx) > AV_PIX_FMT_NONE > }; > const enum AVPixelFormat *pix_fmts; > +AVFilterFormats *fmts_list; > > if (!strcmp(ctx->filter->name, "rgbashift")) > pix_fmts = rgb_pix_fmts; > else > pix_fmts = yuv_pix_fmts; > > -AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts); > +fmts_list = ff_make_format_list(pix_fmts); > if (!fmts_list) > return AVERROR(ENOMEM); > return ff_set_common_formats(ctx, fmts_list); > -- > 2.19.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/vivo: Don't log null value
On 11/25/18, Mark Harris wrote:
> ---
> libavformat/vivo.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/vivo.c b/libavformat/vivo.c
> index c9e9c37f37..9b9189f307 100644
> --- a/libavformat/vivo.c
> +++ b/libavformat/vivo.c
> @@ -166,7 +166,7 @@ static int vivo_read_header(AVFormatContext *s)
> value = strchr(key, ':');
> if (!value) {
> av_log(s, AV_LOG_WARNING, "missing colon in key:value pair
> '%s'\n",
> - value);
> + key);
> continue;
> }
>
> --
> 2.19.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
