>> Only 3 to 4 times? This is easily doable with SIMD.
The problem is not with the thumbnail filter at all. The problem is doing the
transfers from vidmem to sysmem or vice-versa. You will observe if we use a
transcoder pipeline with and without hwaccel cuvid (using hw encoder/decoders
in both
On 11 September 2017 at 05:59, Yogender Gupta wrote:
> I believe there were concerns on pushing the CUDA thumbnail filter and
> that is possible to get similar performance using the normal thumbnail
> filter. The CUDA thumbnail filter is useful for generating thumbnails on
> the hwaccel cuvid pip
I believe there were concerns on pushing the CUDA thumbnail filter and that is
possible to get similar performance using the normal thumbnail filter. The CUDA
thumbnail filter is useful for generating thumbnails on the hwaccel cuvid
pipeline, as it can directly operate on the video memory and gi
2017-09-11 5:46 GMT+08:00 James Almer :
> On 9/10/2017 6:10 PM, Nicolas George wrote:
> > Le quartidi 24 fructidor, an CCXXV, Mark Thompson a écrit :
> >> Input and output formats must be the same, the overlay format must be
> >> the same as the input except possibly with an additional alpha
> com
On 9/10/2017 6:10 PM, Nicolas George wrote:
> Le quartidi 24 fructidor, an CCXXV, Mark Thompson a écrit :
>> Input and output formats must be the same, the overlay format must be
>> the same as the input except possibly with an additional alpha component.
>> ---
>> configure
On 10/09/17 22:10, Nicolas George wrote:
> Le quartidi 24 fructidor, an CCXXV, Mark Thompson a écrit :
>> Input and output formats must be the same, the overlay format must be
>> the same as the input except possibly with an additional alpha component.
>> ---
>> configure |
Le quartidi 24 fructidor, an CCXXV, Mark Thompson a écrit :
> Input and output formats must be the same, the overlay format must be
> the same as the input except possibly with an additional alpha component.
> ---
> configure | 1 +
> libavfilter/Makefile| 2 +
---
libavutil/hwcontext.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 77cf68fe2e..4d0b2a1998 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -216,19 +216,16 @@ static void hwframe_ctx_f
This series adds OpenCL infrastructure to support hwcontext use, with mapping
between OpenCL and some other hardware APIs for GPU-only transformations. (It
has no interaction whatsoever with the existing code in libavutil, and adds no
new external API beyond the enum values.)
It includes two f
---
See example in first mail.
configure | 1 +
libavfilter/Makefile| 1 +
libavfilter/allfilters.c| 1 +
libavfilter/vf_program_opencl.c | 259
4 files changed, 262 insertions(+)
create mode 100644 libavfi
Input and output formats must be the same, the overlay format must be
the same as the input except possibly with an additional alpha component.
---
configure | 1 +
libavfilter/Makefile| 2 +
libavfilter/allfilters.c| 1 +
libavfilter/opencl/overlay.
---
Just some setup code (making output frames and compiling shaders) which will be
needed in every filter.
libavfilter/opencl.c | 244 +++
libavfilter/opencl.h | 87 ++
2 files changed, 331 insertions(+)
create mode 100644 libav
To match creation on a newly-derived device. (This was missed earlier
because the mode is only used in some cases.)
---
libavfilter/vf_hwmap.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
index 8277241dc4..d5fc3c46e6 100644
---
In lavfi only because that's the only current consumer; could be extended if
anyone wants to write OpenCL code for lavc.
libavfilter/Makefile| 6 ++
libavfilter/opencl_source.h | 22 ++
tools/cl2c | 20
3 files changed,
Supports all surface formats in common between the two.
---
configure| 6 +
libavutil/hwcontext_opencl.c | 298 +++
2 files changed, 304 insertions(+)
diff --git a/configure b/configure
index ee5ee58a51..fb21f290b2 100755
--- a/configu
Using cl_arm_import_memory. Unfortunately, despite this not being a
standard extension, the function clImportMemoryARM() is not accessible
via clGetExtensionFunctionAddressForPlatform(). This means that it has
to be linked directly to the ARM OpenCL binary, so making a portable
binary is not poss
Using cl_khr_d3d11_sharing and cl_intel_d3d11_nv12_media_sharing.
---
configure| 6 +
libavutil/hwcontext_opencl.c | 320 ++-
2 files changed, 324 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index c00059067f..8376f
Uses the cl_intel_va_api_media_sharing extension, which supports only
NV12 surfaces and only mapping from QSV to OpenCL.
---
configure| 5 +
libavutil/hwcontext_opencl.c | 365 +++
2 files changed, 370 insertions(+)
diff --git a/config
---
Tries to support all formats expressible in OpenCL, e.g. in Beignet this means:
yuv420p, yuv422p, yuv444p, yuv410p, yuv411p, gray, yuvj420p, yuvj422p, yuvj444p,
nv12, nv21, argb, rgba, abgr, bgra, gray16le, yuv440p, yuvj440p, yuva420p,
yuv420p16le, yuv422p16le, yuv444p16le, ya8, gbrp, gbrp16le
Using cl_khr_dx9_media_sharing.
---
configure| 6 +
libavutil/hwcontext_opencl.c | 396 +++
2 files changed, 402 insertions(+)
diff --git a/configure b/configure
index 84b1d7ad51..c00059067f 100755
--- a/configure
+++ b/configure
@@ -2
---
doc/APIchanges | 3 +++
libavutil/pixdesc.c | 4
libavutil/pixfmt.h | 7 +++
3 files changed, 14 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index cc67cbf6f8..0cea594f25 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
---
This is the same patch as the one in the kmsgrab and rkmpp sets, included here
because the ARM DRM mapping depends on it.
configure | 3 +
libavutil/Makefile | 2 +
libavutil/hwcontext.c | 4 +
libavutil/hwcontext.h | 1 +
libavutil
On Sun, 2017-09-10 at 22:10 +0200, Michael Niedermayer wrote:
> enum {
> INDEX_MPEG2 = 0,
> INDEX_AES3,
> @@ -159,6 +139,26 @@ enum {
> INDEX_H264,
> };
>
> +static const struct {
> +enum AVCodecID id;
> +int index;
> +} mxf_essence_mappings[] = {
> +{ AV_CODEC_ID_MPE
This also moves the enum table up as it is needed earlier
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c | 40
1 file changed, 20 insertions(+), 20 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index cc9ec8c93a..11ccc
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 11ccc8c6ec..1f98daf0f7 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -843,6 +843,7 @@ static void mxf_write_track(AVF
Based on mail from IRT
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c | 17 ++---
tests/ref/fate/copy-trac4914 | 2 +-
tests/ref/lavf/mxf | 6 +++---
3 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/libavformat/mxfenc.c b/libavformat/mx
On Sun, 2017-09-10 at 21:03 +0200, Paul B Mahol wrote:
> +static av_cold int wcap_decode_init(AVCodecContext *avctx)
> +{
> +WCAPContext *s = avctx->priv_data;
> +uint32_t format;
> +
> +if (avctx->extradata && avctx->extradata_size >= 4) {
> +format = AV_RL32(avctx->extradata);
On 9/10/17, Michael Niedermayer wrote:
> They are time consuming operations, performing them after the other checks
> improves the speed with damaged input dramatically.
>
> Fixes: Timeout
> Fixes: 2928/clusterfuzz-testcase-4992812120539136
>
> Found-by: continuous fuzzing process
> https://github
Fixes: runtime error: index 5 out of bounds for type 'int8_t const[5]'
Fixes:3175/clusterfuzz-testcase-minimized-4736774054084608
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_ps.h | 4 +
A value of 5 is allowed
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_ps.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ee31cc093c..c26217e797 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1281,7
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 2 +
libavcodec/allcodecs.c | 2 +
libavcodec/avcodec.h | 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/wcap_parser.c | 124 ++
libavcodec/wcapdec.c | 151 +
They are time consuming operations, performing them after the other checks
improves the speed with damaged input dramatically.
Fixes: Timeout
Fixes: 2928/clusterfuzz-testcase-4992812120539136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Sign
Hello,
Today I've compiled FFmpeg with libopenmpt (N-87255-gcbe181c) for the
first time and I must say I'm very pleased with it. Especially with the
subsong option.
ffmpeg -i "K_vision.umx"
Input #0, libopenmpt, from 'K_vision.umx':
Metadata:
title : Nightvision - Sandman/KFM
Signed-off-by: Ilia Valiakhmetov
---
Changelog | 1 +
1 file changed, 1 insertion(+)
diff --git a/Changelog b/Changelog
index 22928de..ca0758a 100644
--- a/Changelog
+++ b/Changelog
@@ -46,6 +46,7 @@ version :
- haas audio filter
- SUP/PGS subtitle muxer
- convolve video filter
+- VP9 tile th
On 9/10/2017 2:55 PM, Ivan Kalvachev wrote:
> On 9/2/17, James Almer wrote:
> [...]
>> Notes:
>> I have no way to test what effect the removal of XVMC truly has.
>> The decoders are removed but unlike libav we have hwaccels that are not
>> removed by this. Similarly, the pixfmt is also not removed
On 9/2/17, James Almer wrote:
[...]
> Notes:
> I have no way to test what effect the removal of XVMC truly has.
> The decoders are removed but unlike libav we have hwaccels that are not
> removed by this. Similarly, the pixfmt is also not removed in our case.
> Commit dcc39ee10e82833ce24aa57926c00
On Sun, Sep 10, 2017 at 5:17 PM, Martin Vignali
wrote:
> +void (*reorder_pixels)(uint8_t *src, uint8_t *dst, int size);
size should be ptrdiff_t instead of int since it's used as a 64-bit
operand in the asm on x86-64 and the upper 32 bits are undefined
otherwise.
> +++ b/libavcodec/x86/exrds
On 9/9/2017 4:00 AM, LongChair . wrote:
> From: LongChair
>
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding an AVDRMFrameDescriptor struct in buf[0] that
> allows drm / dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
>
> Ch
On Sun, Sep 10, 2017 at 01:31:16PM +0800, Jesse Liu wrote:
> ---
> doc/examples/.gitignore | 1 +
> libavcodec/tests/.gitignore | 1 +
> libavutil/tests/.gitignore | 1 +
> 3 files changed, 3 insertions(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611E
On 9/10/17, Umair Khan wrote:
> On Sun, Sep 10, 2017 at 9:52 PM, Thilo Borgmann
> wrote:
>>
>> Hi,
>>
>> > This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297
>>
>> this is yet another iteration of
>>
>> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/213005.html
>
> I see. I was k
On Sun, Sep 10, 2017 at 9:52 PM, Thilo Borgmann wrote:
>
> Hi,
>
> > This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297
>
> this is yet another iteration of
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/213005.html
I see. I was keepnig reference codec as the source of truth.
Hi,
> This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297
this is yet another iteration of
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/213005.html
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
Hi,
This patch fixes this bug - https://trac.ffmpeg.org/ticket/5297
I suggest removing the check because opt_order can be larger
than block_length for the last frames.
I checked this in reference codec as well. opt_order is larger than
block_length for last 2 frames. Hence, I don't think there's
Hello,
new version in attach
for simd optimization of reorder_pixels
(use by rle and zip uncompress)
pass fate test for me (on Mac Os X)
Tested with the decoding of a sequence of 150 HD Exr images (CGI render
with 17 layers per file in float pixel, ZIP16 compression)
AVX2, seems to provide only
On Sun, Sep 10, 2017 at 12:45:19PM +0800, tiejun.peng wrote:
> non-interleaved process call avio_seek frequently, it will cause some
> performance issues especially in network play scene, such as http/ftp
> protocol.
>
> Signed-off-by: tiejun.peng
> ---
> libavformat/avidec.c | 11 ++-
On Sat, Sep 09, 2017 at 08:02:04PM -0300, James Almer wrote:
> On 9/9/2017 7:47 PM, Michael Niedermayer wrote:
> > On Sat, Sep 09, 2017 at 04:37:52PM -0500, Brian Matherly wrote:
> >>
> >> On 9/9/2017 1:27 PM, Michael Niedermayer wrote:
> >>> +// If the image is sufficiently aligned, co
On Sat, Sep 09, 2017 at 11:24:39PM -0400, Ronald S. Bultje wrote:
> ---
> libavcodec/vp9.c| 15 +--
> libavcodec/vp9dec.h | 2 ++
> 2 files changed, 11 insertions(+), 6 deletions(-)
builds fine too
thanks!
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC7
Hi Richard,
On Sun, Sep 10, 2017 at 6:23 AM, Richard Ling wrote:
> But maybe some time, the filter API could be
> updated so that after a seek, a filter can request frames that are before
> the seek position.
All of this suggests an fast and easy frame-accurate seeking, which is
usually not th
Thanks Marton & Paul.
Flushing filter state after a seek makes good sense. For my proposed
filter (video normalization, with auto gain control) flushing will give a
much more acceptable result than using unrelated frames. For my use case
I'm only interested in transcoding complete files, so I alw
On Sun, 10 Sep 2017, Paul B Mahol wrote:
On 9/10/17, Richard Ling wrote:
I'm thinking of adding a temporal filter (one that relies on context from
previous frames), and I've realised I'm a bit confused about how they
should work.
Say I open a file with ffplay and let it play up to frame 100
50 matches
Mail list logo
