It is unused since 02aa0701ae0dc2def8db640c9e3c06dc1b5de70c.
The corresponding size field is write-only since then.
Signed-off-by: Andreas Rheinhardt
---
I was quite surprised to find this.
libavfilter/af_firequalizer.c | 2 +-
libavfilter/af_loudnorm.c | 6 ++
libavfilter/af_lv2.c
Do this by allocating AVBSFContext together with the data that is
currently in AVBSFInternal; or rather: Put AVBSFContext at the beginning
of a new structure called FFBSFContext (which encompasses more than just
the internal fields and is a proper context in its own right, hence the
name) and remov
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index a883a75380..67963f85c7 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -26,7 +26,7 @@
#includ
This can be achieved by allocating the AVIOContext and
the dynamic buffer's opaque and internal write buffer together.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/libavformat/aviobuf.c b/l
Currently AVIOContext's private fields are all over AVIOContext.
This commit moves them into a new structure in avio_internal.h instead.
Said structure contains the public AVIOContext as its first element
in order to avoid having to allocate a separate AVIOContextInternal
which is costly for those
Possible since 9c3adb7ce23522dcceb264bc0bffd3592dd3e1a5.
Signed-off-by: Andreas Rheinhardt
---
It seems that despite the warning this function is called
after having performed I/O; and that this is intended.
Btw: Shall I move the functions around to avoid the forward
declarations?
libavformat/
It is the more natural place for it given that it only deals with I/O;
in fact, the function already has the ffio prefix and its declaration
already is in avio_internal.h.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 25 +
libavformat/utils.c | 25 -
Don't use the avio-API to read a few bytes at fixed offsets.
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskadec.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index fdfcc86aeb..1977240c
On Wed, 2021-08-04 at 06:34 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Friday, 30 July 2021 04:39
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH] lavfi/qsvvpp: do not mix up FFmpeg
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 66fddf1433..164b07ae6a 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -274,8 +274,10 @@ int6
On Wed, 2021-08-04 at 09:17 +, Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Haihao Xiang
> > Sent: Wednesday, 4 August 2021 10:33
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Haihao Xiang
> > Subject: [FFmpeg-devel] [PATCH v2] avfilter: add QSV variants
On Wed, 2021-08-04 at 10:10 +, Soft Works wrote:
> Haihao,
>
> I've just been looking into the source patch from February:
>
> > > > (We may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021-
> > > > February/276695.html
> > > > to create a connection between two devices too, but this chan
Andreas Rheinhardt:
> Don't rely on the user including it (mostly indirectly).
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mips/constants.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/mips/constants.h b/libavcodec/mips/constants.h
> index df54b3016f..f6eaf
> -原始邮件-
> 发件人: "Jin Bo"
> 发送时间: 2021-08-03 12:05:21 (星期二)
> 收件人: ffmpeg-devel@ffmpeg.org
> 抄送:
> 主题: [FFmpeg-devel] [PATCH v2] configure: [loongson] adjust MMI check in
> configure
>
> After standardizing the use of 'pxor' in commit 'ebedd26', FFmpeg
> build failed with upstream compil
On Thu, Aug 5, 2021 at 2:22 AM Nicolas George wrote:
> Linjie Fu (12021-08-05):
> > > > -if (scale->flags_str) {
> > > > +if (*scale->flags_str) {
> > > It could still be NULL, IIRC.
> > sws_flags doesn't have a candidate for "" (NULL) [1].
> > Hence NULL input for flags leads to a parsin
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Thursday, 5 August 2021 01:22
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Mailing List Delay
>
> On Wed, Aug 04, 2021 at 09:56:53PM +, Soft Wor
On Wed, Aug 04, 2021 at 09:56:53PM +, Soft Works wrote:
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Wednesday, 4 August 2021 23:16
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel]
On 8/4/2021 11:03 PM, Michael Niedermayer wrote:
>>
>> * There is no public documentation on:
>> * Who owns the physical infra.
>
> its all donated one way or another IIRC,
> I am a bit hesitant to post a names who provide the servers in public
> for the main server i think its all on the mai
Signed-off-by: Martin Storsjö
---
libavcodec/aarch64/h264dsp_neon.S | 520 +++---
1 file changed, 260 insertions(+), 260 deletions(-)
diff --git a/libavcodec/aarch64/h264dsp_neon.S
b/libavcodec/aarch64/h264dsp_neon.S
index 997167ca88..997082498f 100644
--- a/libavcodec/a
August 4, 2021 11:17 AM, "Derek Buitenhuis" wrote:
> On 8/3/2021 11:59 PM, Michael Niedermayer wrote:
>
>> somehow this reads a bit offensive to me, iam not sure its meant to
>
> It's not meant as an attack towards you pesonally, but rather to point out
> the absurdity of the situation:
>
> *
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
Benchmarks: A53A72
h264_h_loop_filter_chroma422_10bpp_c: 293.0 116.7
h264_h_loop_filter_chroma422_10bpp_neon: 283.7 126.2
h264_h_loop_filter_chroma_10bpp_c:
On Wed, Aug 04, 2021 at 04:17:53PM +0100, Derek Buitenhuis wrote:
> On 8/3/2021 11:59 PM, Michael Niedermayer wrote:
> > somehow this reads a bit offensive to me, iam not sure its meant to
>
> It's not meant as an attack towards you pesonally, but rather to point out
> the absurdity of the situati
On 8/4/2021 10:15 PM, Michael Niedermayer wrote:
> yes it looks like it is dnsbl & greylisting
> why am i not surprised it is sorbs ...
> anyway i removed sorbs from grossd i hope this wont add too much spam
> to the MLs and ML moderation ques
I will keep an eye out on my next set or two. It has s
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Michael Niedermayer
> Sent: Wednesday, 4 August 2021 23:16
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Mailing List Delay
>
> On Wed, Aug 04, 2021 at 10:58:26PM +0200, Michael
Michael Niedermayer (12021-08-04):
> yes it looks like it is dnsbl & greylisting
Greylisting should whitelist known full mail servers, since they'll
retry later anyway.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ffmpeg
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
transpose_4x8H was declared in vp9lpf_16bpp_neon, however this macro is
not unique to vp9 and could be used elsewhere.
Signed-off-by: Mikhail Nitenko
---
libavcodec/aarch64/neon.S | 13 +
libavcodec/aarch64/vp9lpf_16bpp_neon.S
On Wed, Aug 04, 2021 at 10:58:26PM +0200, Michael Niedermayer wrote:
> On Wed, Aug 04, 2021 at 01:10:00AM +, Soft Works wrote:
> [...]
>
> > Would you be able to take a look into the SMTP logs? I have attached an
> > image from the case that I recently analyzed. It is comparing two messages
These became unnecessary when the stride arguments were changed from
int to ptrdiff_t in bc26fe89275c267d169b468356c82ee59874407d
(0576ef466d8a631326d1d0a5ec2e4c4c81d25353) and
d5d699ab6e6f8a8290748d107416fd5c19757a1b
(aa844dc46f93182a63ec0b53267d19e7342c79b9).
Signed-off-by: Martin Storsjö
---
On 8/4/2021 9:58 PM, Michael Niedermayer wrote:
> This is from february we have august, logs are not kept that long
The email I noted was delayed by 20ish minutes. It's why I revived this thread -
Nicolas noted I should next time it happened.
mbox is here:
https://patchwork.ffmpeg.org/project/ff
On Wed, Aug 04, 2021 at 01:10:00AM +, Soft Works wrote:
[...]
> Would you be able to take a look into the SMTP logs? I have attached an image
> from the case that I recently analyzed. It is comparing two messages that
> were sent at the same time. The left message was received instantly but
On Wed, Aug 04, 2021 at 01:10:00AM +, Soft Works wrote:
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Michael Niedermayer
> > Sent: Wednesday, 4 August 2021 00:59
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-dev
version2:
As second argument for init_get_bits (buf) can be crafted, return value check
for this function call is necessary.
'buf' is part of 'AVPacket pkt'.
replace init_get_bits with init_get_bits8.
---
libavformat/adtsenc.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --
version2:
As second argument for init_get_bits (buf) can be crafted, return value check
for this function call is necessary.
'buf' is part of 'AVPacket pkt'.
replace init_get_bits with init_get_bits8.
---
libavformat/adtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Linjie Fu (12021-08-05):
> > > -if (scale->flags_str) {
> > > +if (*scale->flags_str) {
> > It could still be NULL, IIRC.
> sws_flags doesn't have a candidate for "" (NULL) [1].
> Hence NULL input for flags leads to a parsing issue:
It is not what I am talking about.
The application can s
Maryam Ebrahimzadeh:
> Ping.
>
>> On Aug 3, 2021, at 11:58 AM, maryam ebrahimzadeh wrote:
>>
>> As second argument for init_get_bits (buf) can be crafted, return value
>> check for this function call is necessary.
>> 'buf' is part of 'AVPacket pkt'.
>>
>> ---
>> libavformat/adtsenc.c | 6 -
Ping.
> On Aug 3, 2021, at 11:58 AM, maryam ebrahimzadeh wrote:
>
> As second argument for init_get_bits (buf) can be crafted, return value check
> for this function call is necessary.
> 'buf' is part of 'AVPacket pkt'.
>
> ---
> libavformat/adtsenc.c | 6 --
> 1 file changed, 4 insertion
Nicolas George:
> Andreas Rheinhardt (12021-08-04):
>> Reordering max_lowres is an ABI break.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavcodec/codec.h | 13 +++--
>> 1 file changed, 7 insertions(+), 6 deletions(-)
>
> If it breaks API, then I would rather see it done properly
James Almer:
> On 8/4/2021 1:48 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> On 8/4/2021 1:24 PM, Andreas Rheinhardt wrote:
This gets them off the ABI altogether at the cost of breaking the ABI
once more now.
Signed-off-by: Andreas Rheinhardt
---
Do this and the
Hendrik Leppkes (12021-08-04):
> This seems rather drastic for a change with barely any noticeable
> improvement. I would rather see elements properly grouped by their
> semantics as makes sense, rather than arbitrarily by size.
> Related elements appearing together in the header is overall a more
From: Linjie Fu
Scaler relys on "-sws_flags" option to pass the flags to swscale
and scale filter. Currently passing "sws_flags=xxx" as a filter
option to scaler leads to an incorrect option parsing.
Check and change the string to "flags=xxx" and dumped flags information.
(Refer to parse_sws_fla
Currently the default swscale flags for simple filter graph is bicubic,
however for complex filter graph it uses bilinear as decleared in scale
filter.
$ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
[Parsed_scale_1 @ 0x7f86d2c160c0] w:1920 h:1080 fmt:yuv420p sar:0/1
From: Linjie Fu
Signed-off-by: Linjie Fu
---
fftools/cmdutils.c | 8
fftools/ffplay.c | 2 --
fftools/ffprobe.c | 1 -
3 files changed, 11 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 0b1ef03a25..912e881174 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cm
On 8/4/2021 1:48 PM, Andreas Rheinhardt wrote:
James Almer:
On 8/4/2021 1:24 PM, Andreas Rheinhardt wrote:
This gets them off the ABI altogether at the cost of breaking the ABI
once more now.
Signed-off-by: Andreas Rheinhardt
---
Do this and the preceding patch need a version bump?
You're n
From: Niklas Haas
>From SMPTE RDD 5-2006, the grain seed is to be computed from the
following definition of `pic_offset`:
> When decoding H.264 | MPEG-4 AVC bitstreams, pic_offset is defined as
> follows:
> - pic_offset = PicOrderCnt(CurrPic) + (PicOrderCnt_offset << 5)
> where:
> - PicOrder
On Wed, Aug 4, 2021 at 7:03 PM Nicolas George wrote:
> Linjie Fu (12021-08-04):
> > From: Linjie Fu
> >
> > Currently the default swscale flags for simple filter graph is bicubic,
> > however for complex filter graph it uses bilinear as decleared in scale
> > filter.
> >
> > $ffmpeg -v verbose -
On Wed, Aug 4, 2021 at 6:36 PM Nicolas George wrote:
>
> Andreas Rheinhardt (12021-08-04):
> > Reordering max_lowres is an ABI break.
> >
> > Signed-off-by: Andreas Rheinhardt
> > ---
> > libavcodec/codec.h | 13 +++--
> > 1 file changed, 7 insertions(+), 6 deletions(-)
>
> If it breaks
Andreas Rheinhardt (12021-08-04):
> Good. Because I intend to send another patchset that breaks ABI (but
> only the avpriv-ABI, not the public ABI).
If we lock all libraries version together, we never have to worry about
avpriv ABI.
Regards,
--
Nicolas George
signature.asc
Description: PGP
James Almer:
> On 8/4/2021 1:24 PM, Andreas Rheinhardt wrote:
>> This gets them off the ABI altogether at the cost of breaking the ABI
>> once more now.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Do this and the preceding patch need a version bump?
>
> You're not removing anything that was
Andreas Rheinhardt (12021-08-04):
> Putting child_next besides child_class_iterate is actually nicer.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavutil/log.h | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
Same as for AVCodec: if we break ABI, might as well order fields
On 8/4/2021 1:24 PM, Andreas Rheinhardt wrote:
This gets them off the ABI altogether at the cost of breaking the ABI
once more now.
Signed-off-by: Andreas Rheinhardt
---
Do this and the preceding patch need a version bump?
You're not removing anything that was "public", so IMO no.
Changes in
Andreas Rheinhardt (12021-08-04):
> Reordering max_lowres is an ABI break.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/codec.h | 13 +++--
> 1 file changed, 7 insertions(+), 6 deletions(-)
If it breaks API, then I would rather see it done properly rather than
fortuitously:
Putting child_next besides child_class_iterate is actually nicer.
Signed-off-by: Andreas Rheinhardt
---
libavutil/log.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavutil/log.h b/libavutil/log.h
index 8727c38afc..99625af538 100644
--- a/libavutil/log.h
+++ b
This gets them off the ABI altogether at the cost of breaking the ABI
once more now.
Signed-off-by: Andreas Rheinhardt
---
Do this and the preceding patch need a version bump?
libavformat/avio.h | 98 ++
1 file changed, 47 insertions(+), 51 deletions(
Reordering max_lowres is an ABI break.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/codec.h | 13 +++--
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/libavcodec/codec.h b/libavcodec/codec.h
index cedd106953..8f12705066 100644
--- a/libavcodec/codec.h
+++ b/libavcodec/
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index e92b3dc610..860fbcae5b 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -26,7 +26,7 @@
#includ
This can be achieved by allocating the AVIOContext and
the dynamic buffer's opaque and internal write buffer together.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 22 +-
1 file changed, 9 insertions(+), 13 deletions(-)
diff --git a/libavformat/aviobuf.c b/l
Hello FFmpeg, we need to development a software to capture video type
RTSP/H.264 including its audio. can you tell me where to find the ffmpeg´s
commands or procedures to make it.
thank you
Harold F. Camargo R.
Stream NG
Cel. 318 3227862
Bogotá Colombia
_
Tomas Härdin:
>> -static int64_t mxf_write_cdci_common(AVFormatContext *s, AVStream *st,
>> const UID key)
>> +static int64_t mxf_write_generic_desc(AVFormatContext *s, AVStream *st,
>> const UID key)
>> {
>> MXFStreamContext *sc = st->priv_data;
>> AVIOContext *pb = s->pb;
>> @@ -1115
On 8/4/2021 12:17 PM, Derek Buitenhuis wrote:
On 8/3/2021 11:59 PM, Michael Niedermayer wrote:
somehow this reads a bit offensive to me, iam not sure its meant to
It's not meant as an attack towards you pesonally, but rather to point out
the absurdity of the situation:
* There is no public do
> -static int64_t mxf_write_cdci_common(AVFormatContext *s, AVStream *st, const
> UID key)
> +static int64_t mxf_write_generic_desc(AVFormatContext *s, AVStream *st,
> const UID key)
> {
> MXFStreamContext *sc = st->priv_data;
> AVIOContext *pb = s->pb;
> @@ -1115,7 +1133,7 @@ static i
On 8/3/2021 11:59 PM, Michael Niedermayer wrote:
> somehow this reads a bit offensive to me, iam not sure its meant to
It's not meant as an attack towards you pesonally, but rather to point out
the absurdity of the situation:
* There is no public documentation on:
* Who owns the physical infr
On 8/2/2021 9:55 PM, Derek Buitenhuis wrote:
> ---
> fftools/ffprobe.c | 2 +-
> tests/ref/fate/hls-fmp4_ac3 | 2 +-
Ping.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsub
On 03.08.2021 17:14, Ricardo Monteiro wrote:
Hi Timo,
I do wonder if that information isn't (also) available via metadata on
the incoming frames, so it could be inferred from those by default.
Are you talking about a transcoding scenario? Where you would load the
parameters from the input bi
Martin Storsjö:
> ---
> libavfilter/af_afftfilt.c | 1 +
> libavfilter/avf_showspectrum.c | 1 +
> libavfilter/vaf_spectrumsynth.c | 1 +
> 3 files changed, 3 insertions(+)
>
> diff --git a/libavfilter/af_afftfilt.c b/libavfilter/af_afftfilt.c
> index 3e69c636c8..877ccc5be0 100644
> --- a/
On 8/4/2021 5:36 AM, Soft Works wrote:
-Original Message-
From: ffmpeg-devel On Behalf Of
Haihao Xiang
Sent: Wednesday, 28 July 2021 10:16
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang
Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: update color properties in
codec context
User may
On Fri, 16 Jul 2021, Mikhail Nitenko wrote:
Benchmarks:A53 A72
pred8x8_dc_10_c: 64.249.5
pred8x8_dc_10_neon:62.754.5
pred8x8_dc_128_10_c: 26.015.5
pred8x8_dc_128_10_neon:28.216.0
pred8x8_horiz
This commits refactors the get async result function for common
use in all three backends.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.c | 20
libavfilter/dnn/dnn_backend_common.h | 15 +++
libavfilter/dnn/dnn_backend_openvino.c |
---
libavfilter/af_afftfilt.c | 1 +
libavfilter/avf_showspectrum.c | 1 +
libavfilter/vaf_spectrumsynth.c | 1 +
3 files changed, 3 insertions(+)
diff --git a/libavfilter/af_afftfilt.c b/libavfilter/af_afftfilt.c
index 3e69c636c8..877ccc5be0 100644
--- a/libavfilter/af_afftfilt.c
+++ b/li
This commit enables async execution in the TensorFlow backend
and adds function to flush extra frames.
The async execution mechanism executes the TFInferRequests on
a separate thread which is joined before the next execution of
same TFRequestItem/while freeing the model.
The following is the comp
This commit adds a function for execution of TFInferRequest and documentation
for functions related to TFInferRequest.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_tf.c | 45
1 file changed, 45 insertions(+)
diff --git a/libavfilter/dnn/dnn_b
Since requests are running in parallel, there is inconsistency in
the status of the execution. To resolve it, we avoid using mutex
as it would result in single TF_Session running at a time. So add
TF_Status to the TFRequestItem
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_tf.
This patch adds error handling for cases where the execute_model_tf
fails, clears the used memory in the TFRequestItem and finally pushes
it back to the request queue.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_tf.c | 52 ++--
1 file changed, 36
This commit includes the check for the case when the newly created
TFInferRequest is NULL.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_tf.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_tf.c b/libavfilter/dnn/dnn_backend_tf.c
index 9c9686
This commit adds an async execution mechanism for common use
in the TensorFlow and Native backends.
This commit also adds the documentation of typedefs and functions in
the async module for common use in DNN backends.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.c | 53
The frame allocation and filling the TaskItem with execution
parameters is common in the three backends. This commit shifts
this logic to dnn_backend_common.
Signed-off-by: Shubhanshu Saxena
---
libavfilter/dnn/dnn_backend_common.c | 26 +
libavfilter/dnn/dnn_backend_common.h | 1
---
libavformat/mxf.c| 17
libavformat/mxf.h| 1 +
libavformat/mxfenc.c | 181 +--
3 files changed, 156 insertions(+), 43 deletions(-)
diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index 36d662b58c..677d69e3ab 100644
--- a/libavformat/m
Linjie Fu (12021-08-04):
> From: Linjie Fu
>
> Currently the default swscale flags for simple filter graph is bicubic,
> however for complex filter graph it uses bilinear as decleared in scale
> filter.
>
> $ffmpeg -v verbose -i input.mp4 -vf format=yuv420p,scale=800x600 -an -f null -
> [Parsed_
Xiang, Haihao:
> On Wed, 2021-08-04 at 09:47 +0800, Linjie Fu wrote:
>> Hi Andreas,On Wed, Aug 4, 2021 at 8:30 AM Andreas Rheinhardt <
>> andreas.rheinha...@outlook.com> wrote:
>>
>>> Linjie Fu:
On Wed, Mar 24, 2021 at 2:15 PM Wang, Fei W
>>>
>>> wrote:
> On Mon, 2021-03-22 at 20:12
Haihao,
I've just been looking into the source patch from February:
> > > (We may apply http://ffmpeg.org/pipermail/ffmpeg-devel/2021-
> > > February/276695.html
> > > to create a connection between two devices too, but this change
> > > breaks 'make fate-hwdevice V=2').
I've re-read the discus
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Wednesday, 4 August 2021 10:33
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH v2] avfilter: add QSV variants of the stack
> filters
>
> Include hstack_qsv, vstack_qsv and x
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Haihao Xiang
> Sent: Wednesday, 28 July 2021 10:16
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang
> Subject: [FFmpeg-devel] [PATCH 1/2] lavc/qsvdec: update color properties in
> codec context
>
> User may get color properties
Include hstack_qsv, vstack_qsv and xstack_qsv, some code is copy and
pasted from other filters
Example:
$> ffmpeg -hwaccel qsv -c:v hevc_qsv -i input.h265 -filter_complex
"[0:v][0:v]hstack_qsv" -f null -
---
v2: do not include avfilter.h and add docs for these filters
configure
82 matches
Mail list logo
