Unacceptable. Filter should use frame metadata instead.
Stop avoiding this crucial subject.
On Mon, Mar 8, 2021 at 8:44 PM Anton Khirnov wrote:
> Quoting Nicolas George (2021-03-08 16:32:08)
> > Anton Khirnov (12021-03-08):
> > > I see no reason to believe the format will become more public-wor
We will test vaapi for this patch.
But I am more curious about the software decoder behaviors.
This approach just ref the yuv. Not the intermedia data(like mv, macroblock
type)
Will it have problem if missed frame selected as colPic (Figure 8-2 in spec).
> -Original Message-
> From: ff
Anton Khirnov (12021-03-08):
> As does the likelihood that anybody will actually do any work to polish
> this.
Fair enough.
> The argument for internal side data is literally that it's not good
> enough to be made public. So the option of making it private is used as
> an excuse to avoid designin
Hi all,
I was not able to find any patches or mails, only two open tickets that
mention DRM decryption in some way:
https://trac.ffmpeg.org/ticket/1793
https://trac.ffmpeg.org/ticket/1800
...however there were no updates for years. I do not know it is because
the lack of interest or the lack of
We do not accept DRM code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 2021年3月9日 下午5:44，zsugabubus 写道：
>
> Hi all,
>
> I was not able to find any patches or mails, only two open tickets that
> mention DRM decryption in some way:
>
> https://trac.ffmpeg.org/ticket/1793
> https://trac.ffmpeg.org/ticket/1800
>
> ...however there were no updates for years. I do n
Hi,
On Tue, Mar 09, 2021 at 10:54:22AM +0100, Paul B Mahol wrote:
> We do not accept DRM code.
Hmm. And what about only accepting files that are considered legal?
AVEncryption{,Init}Info and friends are already present. Would it be
much different? They are also take an important role.
And what
On Tue, Mar 09, 2021 at 12:48:45PM +0100, zsugabubus wrote:
> Hi,
>
> On Tue, Mar 09, 2021 at 10:54:22AM +0100, Paul B Mahol wrote:
> > We do not accept DRM code.
>
> Hmm. And what about only accepting files that are considered legal?
DRM is AIDS wrapped in Cancer seasoned with a smidge of Syphi
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-
On Tue, Mar 09, 2021 at 12:58:57PM +0100, Peter White wrote:
> DRM is AIDS wrapped in Cancer seasoned with a smidge of Syphilis.
That's why I would like to share some code with the community. :)
--
zsugabubus
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Tue, Mar 9, 2021 at 3:17 AM Chad Fraleigh wrote:
> On 2/14/2021 10:12 AM, Nuo Mi wrote:
> > On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
> > andreas.rheinha...@gmail.com> wrote:
> >
> >> Nuo Mi:
> >>> ---
> >>> libavutil/opt.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion
Nuo Mi (12021-03-09):
> Or more aggressively, is it feasible to treat all warnings as errors in the
> future? :)
No. Warnings come and go, and a lot of new warnings are bogus.
For example the new warning that tells you that snprintf(buf,
sizeof(buf), "%d", x) will overflow if sizeof(buf) < 11 eve
On Tue, 9 Mar 2021, Martin Storsjö wrote:
Since a0949d0bcb0eee2f3fffcf9a4810c0295d14c0dc, the b-frames
setting defaults to -1, which uses the preset's default setting.
If b-frames are enabled, but max_b_frames is kept at <= 0, the
output dts are inconsistent.
---
libavcodec/nvenc.c | 5 -
1
On 3/9/2021 12:57 PM, Ovchinnikov Dmitrii wrote:
Current settings makes bitrate large, than expected, more information:
https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736
---
libavcodec/amfenc_hevc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/amfenc_hevc.
Hi,
Am 09.03.21 um 16:57 schrieb Ovchinnikov Dmitrii:
> Current settings makes bitrate large, than expected, more information:
> https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736
I agree to the comments on your issue tracker[1], that it would be better to
solve this by setting q
From: Niklas Haas
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to avoid e.g.
chroma interpolation with this filter, although new versions of
libp
On 3/9/2021 1:38 PM, Niklas Haas wrote:
+if (s->skip_av1_grain)
+image.av1_grain = (struct pl_av1_grain_data) {0};
[...]
+if (!s->skip_av1_grain)
+av_frame_remove_side_data(out, AV_FRAME_DATA_FILM_GRAIN_PARAMS);
[...]
+{ "skip_av1_grain", "Disable AV1 grain app
On Tue, 09 Mar 2021 13:53:20 -0300 James Almer wrote:
> On 3/9/2021 1:38 PM, Niklas Haas wrote:
> > +if (s->skip_av1_grain)
> > +image.av1_grain = (struct pl_av1_grain_data) {0};
>
> [...]
>
> > +if (!s->skip_av1_grain)
> > +av_frame_remove_side_data(out, AV_FRAME_DATA_FI
On 3/9/2021 2:18 PM, Niklas Haas wrote:
On Tue, 09 Mar 2021 13:53:20 -0300 James Almer wrote:
On 3/9/2021 1:38 PM, Niklas Haas wrote:
+if (s->skip_av1_grain)
+image.av1_grain = (struct pl_av1_grain_data) {0};
[...]
+if (!s->skip_av1_grain)
+av_frame_remove_side_data
This cap is currently used to mark multithreading-capable codecs that
wrap external libraries with their own multithreading code. The name is
highly confusing for our API users, since libavcodec ALWAYS handles
thread_count=0 (see commit message in previous commit). Therefore rename
the cap and upda
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread
Only one character is actually rewritten.
Fixes truncation warnings, such as
warning: ‘strncpy’ output truncated before terminating nul copying 3 bytes from
a string of the same length [-Wstringop-truncation]
in gcc 10.2.0
---
fftools/cmdutils.c | 4 ++--
1 file changed, 2 insertions(+), 2 delet
Anton Khirnov:
> AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
> codecs that spawn threads internally and are able to select an optimal
> threads count by themselves (all such codecs are wrappers around
> external libraries). It is used by lavc generic code to check whether
Niklas Haas (12021-03-09):
> From: Niklas Haas
>
> This filter conceptually maps the libplacebo `pl_renderer` API into
> libavfilter, which is a high-level image rendering API designed to work
> with an RGB pipeline internally. As such, there's no way to avoid e.g.
> chroma interpolation with thi
> // Change all the ' --' strings to '~--' so that
> // they can be identified as tokens.
> while ((conflist = strstr(str, " --")) != NULL) {
> -strncpy(conflist, "~--", 3);
> +conflist[0] = '~';
> }
Doesn't this simply replace -- with ~- ?
The comment seems wro
Quoting Nicolas George (2021-03-09 10:48:50)
> Anton Khirnov (12021-03-08):
> > The argument for internal side data is literally that it's not good
> > enough to be made public. So the option of making it private is used as
> > an excuse to avoid designing the format properly.
>
> This reasoning w
Anton Khirnov (12021-03-09):
> Correct, I object to using private_ref even more strongly than to
> private side data.
>
> I would prefer private_ref to be removed entirely.
>
> All this said, it would be acceptable to make this new side data private
> (or declared unstable) for a clearly limited
AV_CODEC_CAP_AUTO_THREADS was originally added in b4d44a45f9a to mark
codecs that spawn threads internally and are able to select an optimal
threads count by themselves (all such codecs are wrappers around
external libraries). It is used by lavc generic code to check whether it
should handle thread
On 3/9/2021 4:05 PM, Ovchinnikov Dmitrii wrote:
Current settings makes bitrate large, than expected, more information:
https://github.com/HandBrake/HandBrake/issues/3447#issue-820490736
Thanks for review! updated to "-1" values.
---
libavcodec/amfenc_hevc.c | 2 ++
1 file changed, 2 insertion
Fixes: flac_1040988
Reported-by: Thomas Guilbert
Signed-off-by: Michael Niedermayer
---
libavcodec/flacdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/flacdec.c b/libavcodec/flacdec.c
index cf6128f897..9e55bc1361 100644
--- a/libavcodec/flacdec.c
+++ b/libav
On Sat, Jan 02, 2021 at 02:22:32AM +0100, Michael Niedermayer wrote:
> Fixes: memleak
> Fixes:
> 28686/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5822961932173312
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long since 4.3
Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the cleare
On 3/9/2021 5:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long since 4.3
Thanks
I have three API changes/additions/deprecations on the ml, some for
months
On 3/9/2021 5:30 AM, Nuo Mi wrote:
On Tue, Mar 9, 2021 at 3:17 AM Chad Fraleigh wrote:
On 2/14/2021 10:12 AM, Nuo Mi wrote:
On Mon, Feb 15, 2021 at 2:08 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:
Nuo Mi:
---
libavutil/opt.c | 2 +-
1 file changed, 1 insertion(+), 1 d
If I may ask: will that incorporate the AC-4 patches?
Thanks, Willem Riede.
On Tue, Mar 9, 2021 at 1:47 PM Michael Niedermayer
wrote:
> Hi all
>
> I will branch release/4.4 soon
> then like always leave some time for testing, bugfixes, ... and then
> make FFmeg 4.4 from release/4.4, its too lon
Mar 9, 2021, 17:38 by ffm...@haasn.xyz:
> From: Niklas Haas
>
> This filter conceptually maps the libplacebo `pl_renderer` API into
> libavfilter, which is a high-level image rendering API designed to work
> with an RGB pipeline internally. As such, there's no way to avoid e.g.
> chroma interpola
On 3/9/2021 6:53 PM, Lynne wrote:
Mar 9, 2021, 17:38 by ffm...@haasn.xyz:
From: Niklas Haas
This filter conceptually maps the libplacebo `pl_renderer` API into
libavfilter, which is a high-level image rendering API designed to work
with an RGB pipeline internally. As such, there's no way to a
On Tue, Mar 9, 2021 at 10:37 PM Willem Riede wrote:
>
> If I may ask: will that incorporate the AC-4 patches?
>
The branch will be made from master, if master does not contain them
at that point (which it does not right now), then no.
- Hendrik
___
ffm
On Tue, 09 Mar 2021 22:53:18 +0100 Lynne wrote:
> Sorry, as we discussed on IRC the Vulkan hwcontext should be
> improved first and this filter should be kept as a pure hardware
> filter.
I changed my mind on this because:
- I think it's reasonably self-contained as is, and actually simpler to
Mar 9, 2021, 23:36 by ffm...@haasn.xyz:
> On Tue, 09 Mar 2021 22:53:18 +0100 Lynne wrote:
>
>> Sorry, as we discussed on IRC the Vulkan hwcontext should be
>> improved first and this filter should be kept as a pure hardware
>> filter.
>>
>
> I changed my mind on this because:
>
> - I think it's r
On 3/9/2021 3:47 PM, Michael Niedermayer wrote:
Hi all
I will branch release/4.4 soon
then like always leave some time for testing, bugfixes, ... and then
make FFmeg 4.4 from release/4.4, its too long since 4.3
These three AviSynth demuxer patches should probably go in before 4.4:
http://ffmp
Setting this field happens immediately after the allocation in
ff_cbs_init(), so the whole CBS code may presume that any
CodedBitstreamContext has this set. Lots of code already presumed this,
yet ff_cbs_close() did it inconsistently: It checked before checking
whether the CodedBitstreamType has a
av_bprint_finalize() can still fail even when it has been checked that
the AVBPrint is currently complete: Namely if the string was so short
that it fit into the AVBPrint's internal buffer.
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 7 ---
1 file changed, 4 insertions(+), 3
Fixes Coverity issue #1473546.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_nnedi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_nnedi.c b/libavfilter/vf_nnedi.c
index 4229150668..b273c13944 100644
--- a/libavfilter/vf_nnedi.c
+++ b/libavfilter/vf_nn
Signed-off-by: Andreas Rheinhardt
---
libavcodec/h264_cavlc.c | 152
1 file changed, 76 insertions(+), 76 deletions(-)
diff --git a/libavcodec/h264_cavlc.c b/libavcodec/h264_cavlc.c
index d0548d84f6..9f5f692331 100644
--- a/libavcodec/h264_cavlc.c
+++ b/l
An AVBufferRef (and the corresponding AVBuffer and the underlying actual
buffer) would leak in ff_cbs_sei_add_message() on error in case an error
happened after its creation and before it has been attached to more
permanent storage. Fix this by only creating the AVBufferRef immediately
before attac
(This affected only suffix SEI messages; yet no such SEI messages are
currently inserted.)
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_sei.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/cbs_sei.c b/libavcodec/cbs_sei.c
index c49830ad77..2a96db9674 10064
The only caller to ff_h264_decode_init_vlc() already uses
ff_thread_once() for the call; ergo the check via a simple int with
static storage duration in ff_h264_decode_init_vlc() is redundant.
And if it were not redundant, it would be a potential for data races.
So remove it.
Signed-off-by: Andrea
Otherwise the caller can't distinguish the return value from an error.
Signed-off-by: Andreas Rheinhardt
---
libavutil/avstring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/avstring.c b/libavutil/avstring.c
index e33d4aac51..832bec750f 100644
--- a/libavutil/av
* Support micro seconds for image2 strftime filename
* Support micro seconds for segment strftime filename
* Support duration for segment output
Signed-off-by: tak-matroid
---
libavformat/avformat.h | 7 -
libavformat/img2enc.c | 40 +--
libavformat/segment.c | 61
Hey Nicolas,
Thanks for the comment. I'll split this patch into separate ones and work
on getting them approved sequentially then. Feel free to close this thread
in favor of the upcoming one I just emailed.
*Jiahang (Tak) Li*
Deep Learning Engineer, Matroid Inc
https://www.matroid.com
On Tue, F
> -Original Message-
> From: ffmpeg-devel On Behalf Of Nicolas
> George
> Sent: 2021年3月10日 2:13
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH V5 3/5] libavutil: add side data
> AV_FRAME_DATA_BOUNDING_BOXES
>
> Anton Khirnov (12021-03-09):
> > Cor
From: Christopher Degawa
Used for limiting the size of memory buffers and threads for a target
logical processor count, but does not set thread affinity or the total
amount of threads used, although thread affinities can be controlled
with an additional parameters, it is prefered to add them unti
53 matches
Mail list logo
