> -Original Message-
> From: ffmpeg-devel On Behalf Of Sun,
> Xinpeng
> Sent: Tuesday, December 24, 2019 6:18 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Zhou, Zachary
> Subject: Re: [FFmpeg-devel] [PATCH v1] avfilter: add overlay vaapi filter
>
>
> > -Original Message-
> > From:
On Tue, 31 Dec 2019 at 14:16, Stephen Hutchinson wrote:
> On 12/30/2019 11:11 AM, Matt Oliver wrote:
> > ---
> > compat/avisynth/avisynth_c.h | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
> > index
On 12/30/2019 11:11 AM, Matt Oliver wrote:
---
compat/avisynth/avisynth_c.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 8d17125adc..9ff9321552 100644
--- a/compat/avisynth/avisynth_c.h
+++
On 2019/12/31 上午1:37, Calvin Walton wrote:
On Mon, 2019-12-30 at 12:31 +0100, Marton Balint wrote:
On Mon, 30 Dec 2019, fgodt...@hotmail.com wrote:
From: FgoDt
+@item use_captureblt
+When use gdigrab to capture window or desktop, the mouse cursor
will flicker.
Why? Does this happen with
On 12/30/2019 9:39 PM, Derek Buitenhuis wrote:
> On 30/12/2019 23:50, James Almer wrote:
>> No, it doesn't. The libx264 wrapper disables openGOP by default (by
>> doing the same thing as this patch). Or at least it does now. No idea
>> back then.
>
> It seems to have gone back and forth over the
On Mon, Dec 30, 2019 at 04:36:53PM -0500, Dave Rice wrote:
>
> > On Dec 27, 2019, at 10:49 AM, Paul B Mahol wrote:
> >
> > That is because signalstats is doing more stuff.
>
> signalstats includes options to disable some of the calculations, possibly
> this could be extended to enable or
On Mon, Dec 30, 2019, at 3:18 PM, Audric Ackermann wrote:
> Hi,
>
> I think I already know the answer but I want to play UDP stream (h264 &
> klv) in an android app, and be able to toggle a "recording button" to save
> the data as a file with the exact same input parameters than what is sent
> to
On 30/12/2019 23:53, James Almer wrote:
>> Does multiplying by FF_QP2LAMBDA even make sense here? That contsant
>> is for H.263's QP scale, not HEVC's.
>
> Pretty much every call to ff_side_data_set_encoder_stats() in lavc does
> it, including libx264, so i figure it's expected.
It looks like it
On 30/12/2019 23:50, James Almer wrote:
> No, it doesn't. The libx264 wrapper disables openGOP by default (by
> doing the same thing as this patch). Or at least it does now. No idea
> back then.
It seems to have gone back and forth over the years...
> My objective is having both encoder wrappers
On Sat, 21 Dec 2019 14:54:38 -0800
Philip Langdale wrote:
> On Fri, 20 Dec 2019 16:07:18 -0800
> Josh Allmann wrote:
>
> > One concern I had was about the long-term stability of this
> > behavior. Right now, it works, but perhaps only coincidentally?
> > Being flushable and resumable like this
Hi,
I think I already know the answer but I want to play UDP stream (h264 &
klv) in an android app, and be able to toggle a "recording button" to save
the data as a file with the exact same input parameters than what is sent
to be.
The only way to do this is to decode the whole frame (display
On 12/30/2019 8:06 PM, Derek Buitenhuis wrote:
> On 30/12/2019 19:20, James Almer wrote:
>> +ff_side_data_set_encoder_stats(pkt, x265pic_out.frameData.qp *
>> FF_QP2LAMBDA, NULL, 0, pict_type);
>
> Does multiplying by FF_QP2LAMBDA even make sense here? That contsant
> is for H.263's QP
On 12/30/2019 8:04 PM, Derek Buitenhuis wrote:
> On 30/12/2019 19:20, James Almer wrote:
>> This is in line with the behavior of libx264.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libx265.c | 1 +
>> 1 file changed, 1 insertion(+)
>
> How does this square with
On 30/12/2019 23:37, James Almer wrote:
> We fail for all failed param_parse calls except for the ones from
> x265_opts. I'm fine just printing a warning and letting the encoding
> process continue if you prefer.
>
> I could also make it abort only if explode err_detect flag is set.
No strong
On 12/30/2019 8:10 PM, Derek Buitenhuis wrote:
> On 30/12/2019 19:20, James Almer wrote:
>> +snprintf(cqp, sizeof(cqp), "%d", ctx->cqp);
>> +if (ctx->api->param_parse(ctx->params, "qp", cqp) ==
>> X265_PARAM_BAD_VALUE) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid cqp:
On 12/30/2019 8:07 PM, Derek Buitenhuis wrote:
> On 30/12/2019 19:20, James Almer wrote:
>> +if (ctx->api->param_parse(ctx->params, key, buf) ==
>> X265_PARAM_BAD_VALUE) {
>> +av_log(avctx, AV_LOG_ERROR, "Invalid value %d for param \"%s\".\n",
>> value, key);
>> +return
On 30/12/2019 19:20, James Almer wrote:
> +snprintf(cqp, sizeof(cqp), "%d", ctx->cqp);
> +if (ctx->api->param_parse(ctx->params, "qp", cqp) ==
> X265_PARAM_BAD_VALUE) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid cqp: %d.\n", ctx->cqp);
> +return
On 30/12/2019 19:20, James Almer wrote:
> +if (ctx->api->param_parse(ctx->params, key, buf) ==
> X265_PARAM_BAD_VALUE) {
> +av_log(avctx, AV_LOG_ERROR, "Invalid value %d for param \"%s\".\n",
> value, key);
> +return AVERROR(EINVAL);
> +}
Does returning error make sense
On 30/12/2019 19:20, James Almer wrote:
> +ff_side_data_set_encoder_stats(pkt, x265pic_out.frameData.qp *
> FF_QP2LAMBDA, NULL, 0, pict_type);
Does multiplying by FF_QP2LAMBDA even make sense here? That contsant
is for H.263's QP scale, not HEVC's.
- Derek
On Sat, 28 Dec 2019, Marton Balint wrote:
Since 648b8cca6c56a4fa1760efc72dfe1363a5c6e31e and
c991e9cd91845044e93a9c89dd25b48ae707461b timestamps were not set properly.
Applied the series.
Regards,
Marton
Signed-off-by: Marton Balint
---
libavdevice/xcbgrab.c | 14 +-
1 file
On 30/12/2019 19:20, James Almer wrote:
> This is in line with the behavior of libx264.
>
> Signed-off-by: James Almer
> ---
> libavcodec/libx265.c | 1 +
> 1 file changed, 1 insertion(+)
How does this square with 841c1efc78ace70497187d984adf31c7cc2cd7b6? During
review for that commit, the
Fixes ticket #7528.
Signed-off-by: Marton Balint
---
doc/filters.texi | 5 +
libavfilter/vf_geq.c | 19 ---
2 files changed, 21 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index ba00989987..9572fa36fc 100644
--- a/doc/filters.texi
+++
Also add helper functions to allocate and free such a struct, and make it
usable by providing a new av_eval_expr2 function for which you can specify a
custom AVExprState.
Signed-off-by: Marton Balint
---
doc/APIchanges | 4
libavutil/eval.c| 36
> On Dec 27, 2019, at 10:49 AM, Paul B Mahol wrote:
>
> That is because signalstats is doing more stuff.
signalstats includes options to disable some of the calculations, possibly this
could be extended to enable or disable the ones you want. It would be
interesting to merge these ideas
On Mon, 30 Dec 2019, Michael Niedermayer wrote:
On Sun, Dec 29, 2019 at 05:03:55PM +0100, Marton Balint wrote:
On Sun, 29 Dec 2019, Michael Niedermayer wrote:
On Sat, Dec 28, 2019 at 03:46:24PM +0100, Marton Balint wrote:
Fixes ticket #7528.
Signed-off-by: Marton Balint
---
On Sun, Dec 29, 2019 at 05:03:55PM +0100, Marton Balint wrote:
>
>
> On Sun, 29 Dec 2019, Michael Niedermayer wrote:
>
> >On Sat, Dec 28, 2019 at 03:46:24PM +0100, Marton Balint wrote:
> >>Fixes ticket #7528.
> >>
> >>Signed-off-by: Marton Balint
> >>---
> >> libavfilter/vf_geq.c | 9 +++--
On Sun, Dec 29, 2019 at 04:46:12PM +0100, Marton Balint wrote:
>
>
> On Sun, 29 Dec 2019, Michael Niedermayer wrote:
>
> >On Sat, Dec 28, 2019 at 03:46:23PM +0100, Marton Balint wrote:
> >>Also add helper functions to allocate and free such a struct, and make it
> >>usable by providing a new
This is in line with the behavior of libx264.
Signed-off-by: James Almer
---
libavcodec/libx265.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index a97bf19e91..7049a3144a 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -671,6
Signed-off-by: James Almer
---
No changes.
libavcodec/libx265.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 9646e208f4..a97bf19e91 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -484,6
Signed-off-by: James Almer
---
doc/encoders.texi| 22 ++
libavcodec/libx265.c | 68
2 files changed, 90 insertions(+)
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 673eaf6496..61e674cf96 100644
--- a/doc/encoders.texi
+++
On Mon, 2019-12-30 at 12:31 +0100, Marton Balint wrote:
>
> On Mon, 30 Dec 2019, fgodt...@hotmail.com wrote:
>
> > From: FgoDt
>
> > +@item use_captureblt
> > +When use gdigrab to capture window or desktop, the mouse cursor
> > will flicker.
>
> Why? Does this happen with every windows
On 28/12/2019 23:55, James Almer wrote:
> +if (avctx->gop_size >= 0)
> +ctx->params->keyframeMax = avctx->gop_size;
For this patch and the others, you should call x265_param_parse with the
correct key for these (kind of how librav1e.c does). x265 is not great at
struct ABI
On Mon, 30. Dec 11:31, Andriy Gelman wrote:
> On Tue, 31. Dec 03:02, Matt Oliver wrote:
> > dlopen contains additional security to prevent dll hijacking compared to
> > standard LoadLibrary.
> > ---
> > libavutil/hwcontext_d3d11va.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
>
On Tue, 31. Dec 03:02, Matt Oliver wrote:
> dlopen contains additional security to prevent dll hijacking compared to
> standard LoadLibrary.
> ---
> libavutil/hwcontext_d3d11va.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/hwcontext_d3d11va.c
---
compat/avisynth/avisynth_c.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/avisynth/avisynth_c.h b/compat/avisynth/avisynth_c.h
index 8d17125adc..9ff9321552 100644
--- a/compat/avisynth/avisynth_c.h
+++ b/compat/avisynth/avisynth_c.h
@@ -1096,7 +1096,7 @@
dlopen contains additional security to prevent dll hijacking compared to
standard LoadLibrary.
---
libavutil/hwcontext_d3d11va.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
index 6670c47579..c8ae58f908
From: Zhao Zhili
---
libavcodec/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 8a49234bcd..c935e07538 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -1510,7 +1510,7 @@ int
From: Zhao Zhili
---
libswscale/utils.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libswscale/utils.c b/libswscale/utils.c
index 57c4fd2b0f..c915cf0fca 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -95,7 +95,7 @@ typedef struct FormatEntry {
From: Zhao Zhili
---
libavfilter/vf_dnn_processing.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_dnn_processing.c b/libavfilter/vf_dnn_processing.c
index ce976ec3bd..afb7275a38 100644
--- a/libavfilter/vf_dnn_processing.c
+++
From: Zhao Zhili
---
libavresample/options.c | 6 +++---
libavresample/utils.c | 13 +
2 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/libavresample/options.c b/libavresample/options.c
index 5f08cd7e52..cdab98c357 100644
--- a/libavresample/options.c
+++
From: Zhao Zhili
---
doc/APIchanges| 3 +++
libavutil/pixdesc.c | 5 +
libavutil/pixdesc.h | 5 +
libavutil/pixfmt.h| 2 +-
libavutil/samplefmt.c | 5 +
libavutil/samplefmt.h | 7 ++-
libavutil/version.h | 2 +-
7 files changed, 26 insertions(+), 3 deletions(-)
From: Zhao Zhili
---
libavdevice/lavfi.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index c949ff7e12..fc2336d8fe 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -59,24 +59,28 @@ typedef
From: Zhao Zhili
---
libswscale/tests/swscale.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/libswscale/tests/swscale.c b/libswscale/tests/swscale.c
index 19878a7877..784195f468 100644
--- a/libswscale/tests/swscale.c
+++ b/libswscale/tests/swscale.c
@@
From: Zhao Zhili
Fix av_pix_fmt_desc_get return value check.
---
libavcodec/imgconvert.c | 5 +++--
libavcodec/tests/imgconvert.c | 3 ++-
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/libavcodec/imgconvert.c b/libavcodec/imgconvert.c
index 1fd636c83d..fb0222cdf1 100644
The tests for concat use this option which is scheduled for removal and
does nothing any more. So remove it; otherwise, these tests would fail
at the next major version bump.
Signed-off-by: Andreas Rheinhardt
---
As James has recently suggested that we might bump major in the coming
months [1],
On Mon, 30 Dec 2019, fgodt...@hotmail.com wrote:
From: FgoDt
The commit description should go here, not in the commit title.
Signed-off-by: fgodt
---
doc/indevs.texi | 6 ++
libavdevice/gdigrab.c | 10 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_signalstats.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index 8b2a9ca7c2..1ccc16dd38 100644
--- a/libavfilter/vf_signalstats.c
+++
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_signalstats.c | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index cba14e4fa7..7dadff45b3 100644
---
From: Limin Wang
Signed-off-by: Limin Wang
---
tests/fate/filter-video.mak | 5 +
tests/ref/fate/filter-metadata-signalstats-yuv420p | 1 +
tests/ref/fate/filter-metadata-signalstats-yuv420p10 | 1 +
3 files changed, 7 insertions(+)
create mode 100644
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_signalstats.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index 7dadff45b3..8b2a9ca7c2 100644
--- a/libavfilter/vf_signalstats.c
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_signalstats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c
index abe813d91d..cba14e4fa7 100644
--- a/libavfilter/vf_signalstats.c
+++
This will allow avformat_find_stream_info() get side data from the codec
context.
---
doc/APIchanges | 3 +++
libavformat/avformat.h | 11 +++
libavformat/utils.c| 15 +++
libavformat/version.h | 4 ++--
4 files changed, 31 insertions(+), 2 deletions(-)
diff
My patchset was composed of 7 patchs. The first two have been applied.
There are 5 patchs remaining.
There was no negative feedback since they was sent (20 dec),
so I think they are ready to be merged ?
I have updated the patch 3/7 to current master, I send the revision 5 today.
The following
quinkbl...@foxmail.com (12019-12-30):
> From: Zhao Zhili
>
> ---
> Rebase patch on master.
>
> doc/filters.texi| 8
> libavfilter/buffersrc.c | 14 --
> libavfilter/version.h | 5 -
> 3 files changed, 20 insertions(+), 7 deletions(-)
Pushed, thanks.
Michael Niedermayer (12019-12-30):
> This allows the fuzzer to target meaningfull codec tags instead
> of hunting the 4gb space, which it seems to have problems with.
>
> Suggested-by: James
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.h | 6 ++
> 1 file changed, 6
From: FgoDt
Signed-off-by: fgodt
---
doc/indevs.texi | 6 ++
libavdevice/gdigrab.c | 10 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/doc/indevs.texi b/doc/indevs.texi
index 92bc65be41..43b0bd0465 100644
--- a/doc/indevs.texi
+++ b/doc/indevs.texi
@@
Hi,
For the Libre RISC-V project, I'm going to research the popular codecs
and design new instructions to help speed them up. With ffmpeg being
home to lots of asm folks for many platforms, I also want to ask your
opinion.
What new instructions would you like? Anything particular you find
57 matches
Mail list logo
