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.
Changes from Previous patch :
- Frame colorspace info is n
On 8/2/17, Rodger Combs wrote:
> ---
> Changelog| 2 +
> doc/demuxers.texi| 17
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/cuedec.c | 246
> +++
> libavformat/version.h|
On 06/09/17 04:14, Jun Zhao wrote:
> From a6f3aaa9c1ff6d35d19eef587a49c04916fceca1 Mon Sep 17 00:00:00 2001
> From: Jun Zhao
> Date: Tue, 5 Sep 2017 23:07:15 -0400
> Subject: [PATCH] lavc/vaapi_encode_mpeg2: fix frame rate calc error when use
> time_base.
>
> fix frame rate calc error when use t
On 06/09/17 03:35, Jun Zhao wrote:
> On 2017/8/28 20:28, Mark Thompson wrote:
>> On 24/08/17 02:13, Jun Zhao wrote:
>>> V5: - In h265_vaapi encoder, when setting slice number > max slice number
>>> supported by driver, report error and return. Same as h264_vaapi.
>>> - Clean the logic whe
On 04/08/17 08:25, Jun Zhao wrote:
> V6 : - Re-work with current scale_vaapi and double check i965 have fix the
> sharpness issue.
>https://bugs.freedesktop.org/show_bug.cgi?id=96988
> v5 : - fix the commit message as review(Mark Thompson and Moritz Barsnick)
> - change the magic filt
On 09/09/17 11:28, Mark Thompson wrote:
> On 06/09/17 03:35, Jun Zhao wrote:
>> On 2017/8/28 20:28, Mark Thompson wrote:
>>> On 24/08/17 02:13, Jun Zhao wrote:
V5: - In h265_vaapi encoder, when setting slice number > max slice number
supported by driver, report error and return. Sam
On 09/09/17 08:00, 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.
>
> Chan
On 9/7/17, Nicolas George wrote:
> Le primidi 21 fructidor, an CCXXV, Paul B Mahol a ecrit :
>> ffmpeg -lavfi
>> "testsrc2,trim=end_frame=1,zoompan=z='min(zoom+0.0015,1.5)':d=700:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)'"
>> -f framecrc -
>>
>> Should output 700 frames and not 1 frame.
>
> It does
On Fri, Sep 08, 2017 at 04:02:49AM +0700, Ilia Valiakhmetov wrote:
> Signed-off-by: Ilia Valiakhmetov
>
> v8:
> ---
> libavcodec/vp9.c | 665
> ++-
> libavcodec/vp9_mc_template.c | 202 ++---
> libavcodec/vp9block.c| 522 ++
Fixes: runtime error: left shift of 1073741838 by 1 places cannot be
represented in type 'int32_t' (aka 'int')
Fixes: 3279/clusterfuzz-testcase-minimized-4564805744590848
Suggested-by:
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off
On 9/8/2017 11:15 PM, James Almer wrote:
> It reads eight bytes at a time if the buffer is sufficiently aligned,
> then finishes reading the remaining bytes one at a time.
> If the buffer is unaligned, it reads everything one byte at a time like
> it used to.
>
> See ff_h2645_extract_rbsp() and ad
On Thu, Sep 07, 2017 at 04:17:24PM -0300, James Almer wrote:
> There's no need to wait for the first packet of every stream now that
> every bitstream filter behaves as intended.
>
> Signed-off-by: James Almer
> ---
> What should we do with the AVFMT_FLAG_AUTO_BSF flag? Do we deprecate
> it and f
---
libavcodec/vp9.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..499f357 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -1599,7 +1599,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
s->td[i].uveob[1] = s->td[i].uv
On 9/9/2017 12:41 PM, Michael Niedermayer wrote:
> On Thu, Sep 07, 2017 at 04:17:24PM -0300, James Almer wrote:
>> There's no need to wait for the first packet of every stream now that
>> every bitstream filter behaves as intended.
>>
>> Signed-off-by: James Almer
>> ---
>> What should we do with
This also fixes the warning.
---
libavcodec/vp9.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..f940d60 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -88,7 +88,7 @@ static void vp9_await_tile_progress(VP9Contex
On Sat, Sep 09, 2017 at 03:51:45PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: left shift of 1073741838 by 1 places cannot be
> represented in type 'int32_t' (aka 'int')
> Fixes: 3279/clusterfuzz-testcase-minimized-4564805744590848
>
> Suggested-by:
> Found-by: continuous fuzzing p
On Sat, Sep 09, 2017 at 03:11:00PM +0100, Derek Buitenhuis wrote:
> On 9/8/2017 11:15 PM, James Almer wrote:
> > It reads eight bytes at a time if the buffer is sufficiently aligned,
> > then finishes reading the remaining bytes one at a time.
> > If the buffer is unaligned, it reads everything one
Speeds code up from 50sec to 15sec
Fixes Timeout
Fixes: 3242/clusterfuzz-testcase-5811951672229888
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/scpr.c | 13 -
1 file changed, 12
On Sat, Sep 09, 2017 at 12:13:01PM -0400, Ronald S. Bultje wrote:
> ---
> libavcodec/vp9.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
works
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is dangerous to be right in matters on which the
On Sat, Sep 09, 2017 at 11:24:12PM +0700, gh0st wrote:
> This also fixes the warning.
>
> ---
> libavcodec/vp9.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index a71045e..f940d60 100644
> --- a/libavcodec/vp9.c
> +++ b/libav
Hm, I don't understand, what exactly is the problem? It applies fine for me.
On Sun, Sep 10, 2017 at 1:27 AM, Michael Niedermayer wrote:
> On Sat, Sep 09, 2017 at 11:24:12PM +0700, gh0st wrote:
> > This also fixes the warning.
> >
> > ---
> > libavcodec/vp9.c | 4 ++--
> > 1 file changed, 2 ins
On 9/9/2017 1:27 PM, Michael Niedermayer wrote:
+// If the image is sufficiently aligned, compute 8 samples at once
+if (!(((uintptr_t)dst) & 7)) {
+uint64_t *dst64 = (uint64_t *)dst;
+int w = avctx->width>>1;
+for (x = 0; x
On Sun, Sep 10, 2017 at 01:42:15AM +0700, gh0st wrote:
> Hm, I don't understand, what exactly is the problem? It applies fine for me.
The patch on the mailing list is corrupted by a newline produced
by something in the mail handling, likely on your side.
If you take the patch you sent, its very li
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, compute 8 samples at
> >once
> >+if (!(((uintptr_t)dst) & 7)) {
> >+uint64_t *dst64 = (uint64_t
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, compute 8 samples at
>>> once
>>> +if (!(((uintptr_t)dst) &
Fixes: Timeout (183 ms instead of about 20 sec)
Fixes: 3147/clusterfuzz-testcase-4870592182353920
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/clearvideo.c | 21 +++--
1 file
Fixes: runtime error: left shift of negative value -95
Fixes: 3077/clusterfuzz-testcase-minimized-4684917524922368
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevcdsp_template.c | 2 +-
1 f
Fixes: runtime error: signed integer overflow: 11896 + 2147483646 cannot be
represented in type 'int'
Fixes: 3053/clusterfuzz-testcase-minimized-6355082062856192
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
Hi,
On Sat, Sep 9, 2017 at 2:26 PM, Michael Niedermayer
wrote:
> On Sat, Sep 09, 2017 at 12:13:01PM -0400, Ronald S. Bultje wrote:
> > ---
> > libavcodec/vp9.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
>
> works
>
> thanks
Doesn't actually work for me, for some reason --disabl
---
libavcodec/vp9.c| 15 +--
libavcodec/vp9dec.h | 2 ++
2 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index a71045e..f626f81 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -88,10 +88,8 @@ static void vp9_await_tile_p
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 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/a
---
doc/examples/.gitignore | 1 +
libavcodec/tests/.gitignore | 1 +
libavutil/tests/.gitignore | 1 +
3 files changed, 3 insertions(+)
diff --git a/doc/examples/.gitignore b/doc/examples/.gitignore
index 6bd9dc1508..154c8415f6 100644
--- a/doc/examples/.gitignore
+++ b/doc/examples/.gitign
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. Then I open
the same file with another instance of ffplay and seek directly t
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. Then I open
> the same file with an
34 matches
Mail list logo
