> From: ffmpeg-devel On Behalf Of Fu,
> Linjie
> Sent: Thursday, May 21, 2020 14:38
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Xu, Guangxin
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/hevc_refs: Fix the logic of
> find_ref_idx()
>
> > From: ffmpeg-devel On Beha
On Wed, 27 May 2020, lance.lmw...@gmail.com wrote:
On Wed, May 20, 2020 at 10:31:13PM +0800, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/mpegtsenc.c | 92 +
1 file changed, 47 insertions(+), 45 de
> From: Fu, Linjie
> Sent: Tuesday, May 12, 2020 21:47
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [PATCH] lavc/vaapi_hevc: add missing max_8bit_constraint_flag
>
> This is accidentally missed while rebasing.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/vaapi_hevc.c | 1 +
>
>[FFmpeg-devel] [PATCH 1/3] avformat/rtspdec: use av_dict_set_int() instead
doesn't make sense: instead of what?
Something like
avformat/rtspdec: av_dict_set() -> av_dict_set_int()
would be more clear IMO
--
Anton Khirnov
___
ffmpeg-devel mailing l
Quoting James Almer (2020-05-25 15:41:57)
> On 5/25/2020 10:31 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-05-25 15:21:12)
> >> On 5/25/2020 10:12 AM, Anton Khirnov wrote:
> >>> -/**
> >>> - * Iterate over all registered codecs.
> >>> - *
> >>> - * @param opaque a pointer where libavcode
Quoting lance.lmw...@gmail.com (2020-05-27 06:40:45)
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
The patch looks ok, but it is really unclear why is there a third
version of this patch and what is different about it.
--
Anton Khirnov
___
---
libavcodec/hevc_refs.c | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 73aa6d8caf..4f6d985ae6 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -360,24 +360,14 @@ int ff_hevc_sli
It is only used to store a few local variables within one function,
which is better accomplished by just declaring them on stack explicitly.
Move SliceHeader back from hevc_ps.h to hevdec.h, since it is not
related to parameters sets.
---
libavcodec/hevc_parser.c | 57 +++-
Previously we always set STREAM_TYPE_PRIVATE_DATA, and that remains
the default value.
---
libavformat/mpegtsenc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index bf1a7ee13f..c4e435647d 100644
--- a/libavformat/mpegtsenc.c
+++ b/li
There are two different ways KLV is used in MISB specs - sync and async.
The corresponding text (in ST1401) says:
ISO/IEC 13818-1 Table-34 defines a stream_type = 0x15 for “Metadata carried in
PES packets,”
and Table 2-22 defines a stream_id = 0xFC for “metadata stream.”
and
In ISO/IEC 13818-1,
On Wed, May 27, 2020 at 08:47:54AM +0200, Marton Balint wrote:
>
>
> On Wed, 27 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Tue, May 26, 2020 at 09:52:45PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Wed, 20 May 2020, Marton Balint wrote:
> > >
> > > > The old resync logic had some
On Wed, May 27, 2020 at 10:06:59AM +0200, Anton Khirnov wrote:
> >[FFmpeg-devel] [PATCH 1/3] avformat/rtspdec: use av_dict_set_int() instead
> doesn't make sense: instead of what?
>
> Something like
> avformat/rtspdec: av_dict_set() -> av_dict_set_int()
> would be more clear IMO
Yes, it's more
On Wed, May 27, 2020 at 10:29:21AM +0200, Anton Khirnov wrote:
> Quoting lance.lmw...@gmail.com (2020-05-27 06:40:45)
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
>
> The patch looks ok, but it is really unclear why is there a third
> version of this patch and what is differen
On Wed, May 27, 2020 at 09:06:34AM +0200, Marton Balint wrote:
>
>
> On Wed, 27 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Wed, May 20, 2020 at 10:31:13PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavformat/mpegt
leozhang:
> Signed-off-by: leozhang
> ---
> Please note that this is not a formal patch firstly. I send this to sincerely
> request your suggestions/objections.
>
> And why need operating side data in AVBSFContext? Because I'm planning to
> create a bitstream filter which inject AV_PKT_DATA_SP
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtpproto.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index ca63c16..19e940d 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -301,8 +301,7 @@
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/rtspdec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index bd2e8f4..dfa2991 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -289,9 +289,7 @@ sta
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/prompeg.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/prompeg.c b/libavformat/prompeg.c
index 9770a91..7b2e5e8 100644
--- a/libavformat/prompeg.c
+++ b/libavformat/prompeg.c
@@ -291,8 +291,7 @@ stat
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 23 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_dblur.c | 307 +++
4 files changed, 332 insertions(+)
create mode 100644 libavfilter/vf_dblur.c
diff --git
On 5/27/2020 5:08 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-05-25 15:41:57)
>> On 5/25/2020 10:31 AM, Anton Khirnov wrote:
>>> Quoting James Almer (2020-05-25 15:21:12)
On 5/25/2020 10:12 AM, Anton Khirnov wrote:
> -/**
> - * Iterate over all registered codecs.
> - *
>>>
On 5/27/2020 6:03 AM, Anton Khirnov wrote:
> It is only used to store a few local variables within one function,
> which is better accomplished by just declaring them on stack explicitly.
>
> Move SliceHeader back from hevc_ps.h to hevdec.h, since it is not
> related to parameters sets.
> ---
> l
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of
>Jiaxun Yang
>Sent: Tuesday, May 26, 2020 5:48 PM
>To: ffmpeg-devel@ffmpeg.org
>Cc: yinshi...@loongson.cn; Jiaxun Yang
>Subject: [FFmpeg-devel] [PATCH 1/3] ffbuild: Refine MI
Stop using the deprecated global option
Signed-off-by: James Almer
---
tests/fate/vcodec.mak | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index ec2a9c339d..1e9c0d5647 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.m
On Sun, Mar 29, 2020 at 05:19:29PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #8587, not sure if we want this or not,
> but I do not consider the missing encircled / blinking effect (that is
> not used by our command line tools) an issue.
>
> Please comment, Carl Eugen
On Tue, May 26, 2020 at 01:06:11PM +0200, Paul B Mahol wrote:
> lgtm
will apply
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
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 0cf0df50ef..00a37b175d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1959,7 +1959,7 @@ static int dash_flush(AVFormatContext *s, in
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/codec_desc.c | 7 ++
libavcodec/codec_id.h | 1 +
libavcodec/pnm.c| 21 +---
libavcodec/pnm.h| 2 ++
libavcodec/pnmdec.c | 55 +++
On Thu, Apr 23, 2020 at 04:33:21PM -0700, Dale Curtis wrote:
> This is a patch Chromium has carried for a while, we forgot to send it
> upstream. 7546ac2fee4 made it so that the start_time for mp3 files is
> adjusted for skip_samples. However, this appears incorrect because
> subsequent packet time
On Tue, May 26, 2020 at 6:40 PM James Almer wrote:
>
> Signed-off-by: James Almer
> ---
> Alternatively, we could remove support for libaom 1.0.0, since it's pretty
> much
> unusable. But unfortunately both current Debian Stable and latest Ubuntu LTS
> ship it, so i'm not sure if it would be wis
On Tue, May 26, 2020 at 12:23:41PM -0700, Dale Curtis wrote:
> On Fri, May 22, 2020 at 1:34 PM Michael Niedermayer
> wrote:
>
> >
> > does this produce faster / better code ?
> > that is do compilers actually fail to optimize this from plain
> > clean C code ?
> >
>
> Here's the difference:
> cl
On Wed, May 27, 2020 at 11:10 AM Michael Niedermayer
wrote:
> so the builtin does better and both locally do better than clang on the web
> tool
>
Ah, sorry I forgot godbolt is compiling without any options, if you type
-O9 in the compiler options fields you get:
clang: https://godbolt.org/z/CAM
Hi,
I've run into a regression that I've tracked down to this snippet of
code in libavcodec/decode.c
```
if (hwaccel) {
if (hwaccel->alloc_frame) {
ret = hwaccel->alloc_frame(avctx, frame);
goto fail;
}
} else
avctx->sw_pix_fmt = avctx->pix_f
On Wed, May 27, 2020 at 8:29 AM Michael Niedermayer
wrote:
> what id like to point out here is that the audio stream no
> longer starts at the same time as the video
> also the duration from adding the durations before is
> exact but not afterwards
>
I'm not sure about the duration issue, I'd as
On Wed, May 27, 2020 at 12:20:39PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/codecs.texi | 18 ++
> 1 file changed, 18 insertions(+)
probably correct
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF1336
On Sat, May 16, 2020 at 06:48:08PM +0200, Paul B Mahol wrote:
> On 5/16/20, Zane van Iperen wrote:
> > On Sat, 16 May 2020 15:03:22 +0200
> > "Paul B Mahol" wrote:
> >
> >>
> >> Why sending this kind of patches?
> >>
> >> I see no point in this patch?
> >>
> >
> > Michael suggested it here
> > ht
On Wed, May 27, 2020 at 11:27:14AM -0700, Dale Curtis wrote:
> On Wed, May 27, 2020 at 11:10 AM Michael Niedermayer
> wrote:
>
> > so the builtin does better and both locally do better than clang on the web
> > tool
> >
>
> Ah, sorry I forgot godbolt is compiling without any options, if you type
On Wed, 27 May 2020, lance.lmw...@gmail.com wrote:
On Wed, May 27, 2020 at 08:47:54AM +0200, Marton Balint wrote:
On Wed, 27 May 2020, lance.lmw...@gmail.com wrote:
> On Tue, May 26, 2020 at 09:52:45PM +0200, Marton Balint wrote:
> >
> >
> > On Wed, 20 May 2020, Marton Balint wrote:
> >
On Sun, Mar 15, 2020 at 10:20:56PM +0100, Michael Niedermayer wrote:
> This combination skips allocating large padding which can read out of array
>
> Fixes:
> 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5746381832847360
>
> Found-by: continuous fuzzing process
> https:/
On Sun, Mar 15, 2020 at 10:20:58PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (170sec -> 6sec)
> Fixes:
> 20956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5713643025203200
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects
On Mon, Apr 20, 2020 at 12:21:22AM +0200, Michael Niedermayer wrote:
> high resolutions with only small blocks appear to be rather
> slow with the fuzzer + sanitizers.
> A solution which makes this run faster is welcome.
>
> Fixes: Timeout (did not wait -> 17sec)
> Fixes:
> 21006/clusterfuzz-test
On Wed, 27 May 2020 at 22:53, Michael Niedermayer
wrote:
> On Sun, Mar 15, 2020 at 10:20:56PM +0100, Michael Niedermayer wrote:
> > This combination skips allocating large padding which can read out of
> array
> >
> > Fixes:
> 20978/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-57
From dad3ee4f5e396bf90d4cd43562e238920ad84f02 Mon Sep 17 00:00:00 2001
From: oreo639 <31916379+oreo...@users.noreply.github.com>
Date: Wed, 27 May 2020 16:54:19 -0700
Subject: [PATCH] avformat/ogg: Add partial support for demuxing
---
libavformat/Makefile | 1 +
libavformat/oggdec.c |
On 5/27/2020 9:10 PM, A G wrote:
> From dad3ee4f5e396bf90d4cd43562e238920ad84f02 Mon Sep 17 00:00:00 2001
> From: oreo639 <31916379+oreo...@users.noreply.github.com>
> Date: Wed, 27 May 2020 16:54:19 -0700
> Subject: [PATCH] avformat/ogg: Add partial support for demuxing
This patch is barely diffe
> this time you didn't even include the relevant disclaimer.
That was a mistake, sorry.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-req
From 81cf2038424e483e60ed9747f965ec452d357773 Mon Sep 17 00:00:00 2001
From: oreo639 <31916379+oreo...@users.noreply.github.com>
Date: Wed, 27 May 2020 17:18:03 -0700
Subject: [PATCH] avformat/oggenc: Add partial support for OggPCM muxing
This adds partial support for OggPCM demuxing.
Heavily base
This adds partial support for OggPCM muxing.
It is effectively just an updated version of this:
https://ffmpeg.org/pipermail/ffmpeg-devel/2013-July/145556.html
---
libavformat/Makefile | 1 +
libavformat/oggdec.c | 1 +
libavformat/oggdec.h | 1 +
libavformat/oggparsepcm.c |
On Wed, May 27, 2020 at 09:37:00PM +0200, Michael Niedermayer wrote:
> On Wed, May 27, 2020 at 12:20:39PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/codecs.texi | 18 ++
> > 1 file changed, 18 insertions(+)
>
> pr
On Wed, 27 May 2020 22:11:41 +0200
"Michael Niedermayer" wrote:
>
> will apply
>
> thx
>
Thanks! Could you please also apply part 4 (the muxer)? The encoder's
useless without it.
Zane
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ff
0002-avcodec-h264dec-Add-h264-VPE-HW-decoder.patch
Description: 0002-avcodec-h264dec-Add-h264-VPE-HW-decoder.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
0001-avutil-hwcontext-Add-VPE-implementation.patch
Description: 0001-avutil-hwcontext-Add-VPE-implementation.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
0003-avcodec-hevcdec-Add-hevc-VPE-HW-decoder.patch
Description: 0003-avcodec-hevcdec-Add-hevc-VPE-HW-decoder.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
0005-avcodec-h26xenc-Add-h264-hevc-VPE-HW-encoder.patch
Description: 0005-avcodec-h26xenc-Add-h264-hevc-VPE-HW-encoder.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit l
0004-avcodec-vp9dec-Add-vp9-VPE-HW-decoder.patch
Description: 0004-avcodec-vp9dec-Add-vp9-VPE-HW-decoder.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or
0006-vcodec-vp9enc-Add-VP9-VPE-HW-encoder.patch
Description: 0006-vcodec-vp9enc-Add-VP9-VPE-HW-encoder.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or em
0008-vfilter-pp-Add-VPE-post-processing-filter.patch
Description: 0008-vfilter-pp-Add-VPE-post-processing-filter.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link ab
0007-avfilter-spliter-Add-VPE-spliter-filter.patch
Description: 0007-avfilter-spliter-Add-VPE-spliter-filter.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above,
On 5/27/2020 3:55 PM, Pavel Koshevoy wrote:
> Hi,
>
> I've run into a regression that I've tracked down to this snippet of
> code in libavcodec/decode.c
> ```
> if (hwaccel) {
> if (hwaccel->alloc_frame) {
> ret = hwaccel->alloc_frame(avctx, frame);
> goto fail;
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhang, Guiyong
> Sent: Thursday, May 28, 2020 4:12 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] aubmit Verisilicon VPE hardware codec
> implementation
>
Hello Guiyong,
I'm curious - which actual products does that s
Hi softworkz,
This serial patches are Verislicon Hantro hardware codecs which include
decoder/encoder/transcoding/post processing functions.
It's used in Facebook transcoding project - multiple transcoding boards
installed on a x86 server VIA PCIE interface to do video transcoding job.
FFmpeg
On Thu, May 28, 2020 at 10:22 AM Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Zhang, Guiyong
> > Sent: Thursday, May 28, 2020 4:12 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: [FFmpeg-devel] aubmit Verisilicon VPE hardware codec
> > implementatio
fix ticket: 8688
should goto failed workflow if cannot get usable string by ff_make_absolute_url
Signed-off-by: Steven Liu
---
libavformat/hls.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 3e35d157ad..a9592dea5e 100644
fix ticket: 8687
workflow should return if there have no value of strchr
Signed-off-by: Steven Liu
---
libavformat/url.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/url.c b/libavformat/url.c
index 6956f6dc10..20463a6674 100644
--- a/libavformat/url.c
+++ b/libavformat/ur
Hi softworkz,
Yes you are right, the FFmpeg VPE codecs work together with VPI:
https://github.com/VeriSilicon/VPI
VPI includes source code(vpi/src) and some so library(sdk_libs).
Thanks,
GY
-邮件原件-
发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 myp...@gmail.com
发送时间: 2020年
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhang, Guiyong
> Sent: Thursday, May 28, 2020 4:38 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] 答复: aubmit Verisilicon VPE hardware codec
> implementation
>
> Hi softworkz,
>
>
Squash new pixel format into the ENUM structure would lead to an ABI break.
Would be better to append at the end. (Before AV_PIX_FMT_NB)
-Linjie
From: ffmpeg-devel On Behalf Of Zhang, Guiyong
Sent: Thursday, May 28, 2020 10:12
To: ffmpeg-devel@ffmpeg.org
Subject: [FFmpeg-devel] aubmit Verisilico
Hi softworkz,
Currently no- but similar module maybe possible in further.
Thanks,
GY
-邮件原件-
发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 Soft Works
发送时间: 2020年5月28日 10:47
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] 答复: aubmit Verisilicon VPE ha
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Zhang, Guiyong
> Sent: Thursday, May 28, 2020 4:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: [FFmpeg-devel] 答复: 答复: aubmit Verisilicon VPE hardware codec
> implementation
>
> Hi softworkz,
>
> -Original Message-
> From: ffmpeg-devel On Behalf Of Ting Fu
> Sent: 2020年5月25日 22:46
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 2/2] dnn-layer-mathunary-test: add unit test
> for
> abs
>
> Signed-off-by: Ting Fu
> ---
> tests/dnn/.gitignore | 1
They specifically focused on transcoding only:)
-邮件原件-
发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 Soft Works
发送时间: 2020年5月28日 11:04
收件人: FFmpeg development discussions and patches
主题: Re: [FFmpeg-devel] 答复: 答复: aubmit Verisilicon VPE hardware codec
implementation
> -
> From: ffmpeg-devel On Behalf Of
> Anton Khirnov
> Sent: Wednesday, May 27, 2020 16:48
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] hevc_refs: reduce code duplication in
> find_ref_idx()
>
> ---
> libavcodec/hevc_refs.c | 22 ++
> 1 file changed, 6 inserti
Sorry the way sent this patch is incorrect, so please stop reviewing this patch
in this thread, I will re-submit it in another email.
-邮件原件-
发件人: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] 代表 Zhang, Guiyong
发送时间: 2020年5月28日 10:12
收件人: ffmpeg-devel@ffmpeg.org
主题: [FFmpeg-devel]
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine for multi
formats video encoding and decoding.
It is used with the VPE hwaccel codec API and library to initialize and
use a VPE device which is within the hwcontext libavutil framework.
These VPE codecs are used in transcoding project -
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine
for multi formats video encoding and decoding.
This decoder uses VPI(VPE Interface) API and library for h264 decoding.
Signed-off-by: Qin.Wang
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allc
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine
for multi formats video encoding and decoding.
This decoder uses VPI(VPE Interface) API and library for vp9 decoding.
Signed-off-by: Qin.Wang
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c |
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine
for multi formats video encoding and decoding.
This decoder uses VPI(VPE Interface) API and library for hevc decoding.
Signed-off-by: Qin.Wang
---
configure| 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine for multi
formats video encoding and decoding.
This encoder uses VPI(VPE Interface) API and library for h264 and hevc
encoding.
Signed-off-by: rxchen
---
configure| 2 +
libavcodec/Makefile | 2 +
libavcodec/all
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine for multi
formats video encoding and decoding.
This encoder uses VPI(VPE Interface) API and library for vp9 encoding.
Signed-off-by: Guiyong.zhang
---
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodec
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine
for multi formats video encoding and decoding.
This filter splite one input to multi output with different picture data.
Signed-off-by: Qin.Wang
---
configure| 1 +
libavfilter/Makefile | 1 +
libavfilter
VPE(Video Pipeline Engine) is VeriSilicon's hardware engine for multi
formats video encoding and decoding.
This filter uses VPI(VPE Interface) API and library for raw video
frame post-processing.
The input of this filter is raw video data, it supports most of the
popular raw data formats like NV1
79 matches
Mail list logo
