> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Michael Niedermayer
> Sent: Thursday, January 17, 2019 8:30 PM
> To: FFmpeg development discussions and patches
> Cc: Nicolas George
> Subject: Re: [FFmpeg-devel] [PATCH v3] Improved the perf
On 1/17/19 2:35 PM, Karthick J wrote:
> For low latency streaming even milliseconds matter!
> ---
> libavformat/dashenc.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index cfd0f601d4..9c90cf17e5 100644
>
Optimize put_hevc_qpel_bi_hv_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 11.4%(2.01x to 2.24x,
tested on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 ++
libavcodec/mips/hevcdsp_mips.h | 12 +-
libavcodec/mips/h
Optimize put_hevc_qpel_hv_8 with mmi in the case width=4/8/12/16/24/32/48/64.
This optimization improved HEVC decoding performance 11%(1.81x to 2.01x, tested
on loongson 3A3000).
---
libavcodec/mips/hevcdsp_init_mips.c | 9 ++
libavcodec/mips/hevcdsp_mips.h | 37 +--
libavcodec/mips/h
Using MSDK parser can improve qsv decoder pass rate in some cases (E.g:
sps declares a wrong level_idc, smaller than it should be).
And it is necessary for adding new qsv decoders such as MJPEG and VP9
since current parser can't provide enough information.
Actually using MFXVideoDECODE_DecodeHeader
Signed-off-by: Zhong Li
---
libavcodec/qsv.c | 18 ++
libavcodec/qsv_internal.h | 2 ++
2 files changed, 20 insertions(+)
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index bb0d795..224bc00 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -196,6 +196,24 @@ in
Signed-off-by: Zhong Li
---
Changelog | 1 +
configure | 1 +
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsvdec_other.c | 28 +++-
5 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/Changelog
Signed-off-by: Zhong Li
---
configure | 10 +-
libavcodec/qsvdec.c | 16 +---
libavcodec/qsvdec.h | 2 --
3 files changed, 6 insertions(+), 22 deletions(-)
diff --git a/configure b/configure
index c2b8fac..946f534 100755
--- a/configure
+++ b/configure
@@ -2957,7 +
Replace current parser with MFXVideoDECODE_DecodeHeader(),
and add MJPEG/VP9 decoders.
Zhong Li (5):
lavc/qsvdec: add function ff_qsv_map_picstruct()
lavc/qsvdec: Replace current parser with MFXVideoDECODE_DecodeHeader()
lavc/qsvdec: remove orignal parser code since not needed now
lavc/qsv
VP9 decoder is support on Intel kabyLake+ platforms with MSDK Version 1.19+
Signed-off-by: Zhong Li
---
Changelog | 1 +
configure | 1 +
libavcodec/allcodecs.c| 1 +
libavcodec/qsv.c | 5 +
libavcodec/qsvdec_other.c | 46 +
Marton Balint (12019-01-04):
> Agreed, and this is how it should work even after the patch. user_duration
> which is the duration specified in the ffconcat file always have priority
> because get_best_effort_duration always considers that first. So it does not
> matter that we assign ConcatFile->du
On 1/14/19, Paul B Mahol wrote:
> On 1/13/19, Paul B Mahol wrote:
>> On 1/13/19, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> doc/filters.texi | 14 ++
>>> libavfilter/Makefile | 1 +
>>> libavfilter/allfilters.c | 1 +
>>> libavfilter/vf_colorkey.c | 93
Paul B Mahol (12019-01-21):
> Time have come to apply this.
Not unless you fix the flaws. Get somebody to do a proper review.
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> Time have come to apply this.
>
> Not unless you fix the flaws. Get somebody to do a proper review.
>
This was reviewed, and I will apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@f
Paul B Mahol (12019-01-21):
> This was reviewed, and I will apply it.
I see no trace of it on the mailing-list. And if it was true, the flaw I
spotted would have been fixed.
If you apply as is, I will revert.
Get a REAL review, public, on the mailing list.
Regards,
--
Nicolas George
signa
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> This was reviewed, and I will apply it.
>
> I see no trace of it on the mailing-list. And if it was true, the flaw I
> spotted would have been fixed.
>
> If you apply as is, I will revert.
Michael will remove your commit rights th
Paul B Mahol (12019-01-21):
> You are blocking my patch,
Yes I am blocking your patch: it is bad. Fix it.
*Your* rights should be revoked if you push without review.
> and not providing useful review at all.
I do not owe you a review. You have been repeatedly rude towards me, why
should I make
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> You are blocking my patch,
>
> Yes I am blocking your patch: it is bad. Fix it.
>
> *Your* rights should be revoked if you push without review.
No.
>> and not providing useful review at all.
>
> I do not owe you a review. You hav
Paul B Mahol (12019-01-21):
> You can only block patch if you provide actual review.
> Those are rules.
You just invented that rule.
There is a flaw, do not push without fixing it. I stand firm on it will
not repeat it.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> You can only block patch if you provide actual review.
>> Those are rules.
>
> You just invented that rule.
No, see Michael commits patches without review (thank Carl, not from
you) all the time.
>
> There is a flaw, do not push
Paul B Mahol (12019-01-21):
> No, see Michael commits patches without review (thank Carl, not from
> you) all the time.
Yes, but not when flaws were pointed.
> You have not provided actual review,
Once again: I will not, I do not owe you my time.
> just pointed some minor nuisance.
"Minor" is
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> No, see Michael commits patches without review (thank Carl, not from
>> you) all the time.
>
> Yes, but not when flaws were pointed.
>
>> You have not provided actual review,
>
> Once again: I will not, I do not owe you my time.
T
Paul B Mahol (12019-01-21):
> They why you reply to my patches at all?
Because they are bad. I am not doing it for you, I am doing it for the
project.
> Or what? I'm ignoring you all the time, and nobody cares.
Thanks, you just said explicitly that you violated the rules of this
project. This wi
On 1/21/19, Nicolas George wrote:
> Paul B Mahol (12019-01-21):
>> They why you reply to my patches at all?
>
> Because they are bad. I am not doing it for you, I am doing it for the
> project.
This really hurts me, because its obviously not correct. And you are
doing this for your minor pride an
On 11/10/18, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/Makefile | 1 +
> libavfilter/af_astretch.c | 330 ++
> libavfilter/allfilters.c | 1 +
> 3 files changed, 332 insertions(+)
> create mode 100644 libavfilter/af_astre
Patches to follow:
[PATCH 1/2] avutil: Rename RSHIFT macro to ROUNDED_RSHIFT
[PATCH 2/2] avcodec: Change uses of RSHIFT to ROUNDED_RSHIFT
This is my first patch submission to ffmpeg (and at a tense
moment, it seems, but soldiering on...), please bear with me.
The RSHIFT macro in libavutil/common
Three files in libavcodec/ use the RSHIFT macro from libavutil:
- mpeg4videodec.c
- vp3.c
- vp56.c
All instances of RSHIFT are updated to follow the name-change
in libavutil/common.h (previous commit).
Signed-off-by: FeRD (Frank Dana)
---
libavcodec/mpeg4videodec.c | 4 ++--
libavcodec/vp3.c
libavutil/common.h contains a pair of macros on lines 54-55, which
the comment on line 53 describes as "rounded division & shift".
The division macro is named ROUNDED_DIV. The shift macro is named
RSHIFT. Since "RSHIFT" is a common name for a bitwise right-shift
operation without rounding (see e.g
The compiled libavcodec/tests/codec_desc was left out of that dir's
.gitignore when the test was added, so it shows up in 'git status'
as an untracked file if it's been built.
Signed-off-by: FeRD (Frank Dana)
---
libavcodec/tests/.gitignore | 1 +
1 file changed, 1 insertion(+)
diff --git a/lib
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Zhong Li
> Sent: Monday, January 21, 2019 4:42 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Li, Zhong
> Subject: [FFmpeg-devel] [PATCH 0/5] Refact qsv decoder parser and add new
> decoders
>
> Re
On Mon, Jan 21, 2019 at 12:38:58 -0500, FeRD (Frank Dana) wrote:
> After applying both patches, 'make fate' succeeds and ffmpeg is still
> functional.
You're not allowed to break fate (or compilation). So the two pathes
need to be merged.
If, OTOH, the libraries are to be considered independent,
On Mon, Jan 21, 2019 at 1:55 PM Moritz Barsnick wrote:
> On Mon, Jan 21, 2019 at 12:38:58 -0500, FeRD (Frank Dana) wrote:
>
> > After applying both patches, 'make fate' succeeds and ffmpeg is still
> > functional.
>
> You're not allowed to break fate (or compilation). So the two pathes
> need to
The RSHIFT macro in libavutil/common.h does not actually perform
a bitwise right-shift, but rather a rounded version of the same
operation, as is noted by a comment above the macro. The rounded
divsion macro on the very next line is named ROUNDED_DIV, which
seems far more clear.
This patch renames
On Mon, Jan 21, 2019 at 08:19:38AM +, Wang, Shaofei wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > Michael Niedermayer
> > Sent: Thursday, January 17, 2019 8:30 PM
> > To: FFmpeg development discussions and patches
> > Cc:
On 1/21/2019 4:09 PM, FeRD (Frank Dana) wrote:
> The RSHIFT macro in libavutil/common.h does not actually perform
> a bitwise right-shift, but rather a rounded version of the same
> operation, as is noted by a comment above the macro. The rounded
> divsion macro on the very next line is named ROUND
On Mon, Jan 14, 2019 at 07:14:13PM +0100, Paul B Mahol wrote:
> On 1/14/19, Nicolas George wrote:
> > Paul B Mahol (12019-01-14):
> >> Will apply ASAP!
> >
> > I have spotted at least one problem (conditional compilation) but I have
> > no time to make a real review until at least ten days, alas.
On Mon, Jan 21, 2019 at 01:21:51PM -0500, FeRD (Frank Dana) wrote:
> The compiled libavcodec/tests/codec_desc was left out of that dir's
> .gitignore when the test was added, so it shows up in 'git status'
> as an untracked file if it's been built.
>
> Signed-off-by: FeRD (Frank Dana)
> ---
> li
On Mon, Jan 21, 2019 at 06:10:24PM +0800, Shiyou Yin wrote:
> Optimize put_hevc_qpel_hv_8 with mmi in the case width=4/8/12/16/24/32/48/64.
> This optimization improved HEVC decoding performance 11%(1.81x to 2.01x,
> tested on loongson 3A3000).
> ---
> libavcodec/mips/hevcdsp_init_mips.c | 9 ++
Hi, I noticed that ffmpeg supports CENC AES-CTR:
https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-August/033130.html
Are there any plans to add the other 3 common encryption protection
schemes: cbc1, cens, and cbcs? I'm mainly interested in cbcs as I believe
it's the only one used with HLS.
--
params.pipeline_flags:
https://github.com/intel/libva/blob/master/va/va_vpp.h#L503-L529
params.filter_flags:
https://github.com/intel/libva/blob/master/va/va.h#L217-L220
Signed-off-by: Zachary Zhou
---
libavfilter/vf_deinterlace_vaapi.c | 4
libavfilter/vf_misc_vaapi.c| 10 +++
On Mon, Jan 21, 2019 at 3:54 PM James Almer wrote:
> On 1/21/2019 4:09 PM, FeRD (Frank Dana) wrote:
> > diff --git a/libavutil/common.h b/libavutil/common.h
> > index 8db0291170..0bff7f8f72 100644
> > --- a/libavutil/common.h
> > +++ b/libavutil/common.h
> > @@ -51,7 +51,7 @@
> > #endif
> >
> >
> 在 2019年1月22日，上午8:34，Peter Tseng 写道：
>
> Hi, I noticed that ffmpeg supports CENC AES-CTR:
> https://lists.ffmpeg.org/pipermail/ffmpeg-user/2016-August/033130.html
>
> Are there any plans to add the other 3 common encryption protection
> schemes: cbc1, cens, and cbcs? I'm mainly interested in
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 52c50a1..2d29427 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -46,7 +46,6 @@ typedef struct XAVS2EContext {
int min_qp;
Signed-off-by: hwrenx
---
libavcodec/libdavs2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdavs2.c b/libavcodec/libdavs2.c
index cf75656..f8f1b05 100644
--- a/libavcodec/libdavs2.c
+++ b/libavcodec/libdavs2.c
@@ -45,10 +45,11 @@ static av_cold int davs2_in
Signed-off-by: hwrenx
---
libavcodec/libxavs2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
index 2d29427..0ad9ca9 100644
--- a/libavcodec/libxavs2.c
+++ b/libavcodec/libxavs2.c
@@ -109,8 +109,9 @@ static av_cold int xavs2
On Tue, Jan 22, 2019 at 2:38 PM hwrenx wrote:
>
> Signed-off-by: hwrenx
> ---
> libavcodec/libxavs2.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/libxavs2.c b/libavcodec/libxavs2.c
> index 52c50a1..2d29427 100644
> --- a/libavcodec/libxavs2.c
> +++ b/libavcodec/libxavs2.c
Khronos OpenCL header (https://github.com/KhronosGroup/OpenCL-Headers)
uses cl_va_api_media_sharing_intel.h. And Intel's official OpenCL driver
for Intel GPU (https://github.com/intel/compute-runtime) was compiled
against Khronos OpenCL header. So it's better to align with Khronos.
Signed-off-by:
These functions can be reused by other colorspace filters,
so move them to common file. No functional changes.
Signed-off-by: Ruiling Song
---
libavfilter/colorspace.c| 71
libavfilter/colorspace.h| 4 +++
libavfilter/vf_colorspace.c | 80 +++
Signed-off-by: Ruiling Song
---
libavfilter/opencl/colorspace_common.cl | 25 -
libavfilter/vf_tonemap_opencl.c | 64 +++--
2 files changed, 29 insertions(+), 60 deletions(-)
diff --git a/libavfilter/opencl/colorspace_common.cl
b/libavfilter/openc
Some filters may not need to do linearize/delinearize, thus
will even not define them. Add ifdef check, so they could easily
re-use the .cl file.
Signed-off-by: Ruiling Song
---
libavfilter/opencl/colorspace_common.cl | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --
This is used to print a 3x3 matrix into a part of OpenCL
source code.
Signed-off-by: Ruiling Song
---
libavfilter/opencl.c | 13 +
libavfilter/opencl.h | 8
2 files changed, 21 insertions(+)
diff --git a/libavfilter/opencl.c b/libavfilter/opencl.c
index ac5eec6..95f0bfc 10
On 21.01.2019 17:43, Paul B Mahol wrote:
On 11/10/18, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_astretch.c | 330 ++
libavfilter/allfilters.c | 1 +
3 files changed, 332 insertions(+)
crea
52 matches
Mail list logo
