Re: [FFmpeg-devel] [PATCH 3/3] avfilter/find_rect: write score to metadata
On 2021-04-03 21:44, Gyan Doshi wrote:
Plan to push set tomorrow.
Pushed as
aff23c3474f93d7f08422755a55da4ba3ce1e800
abdafca9ad26b020b13b76d538a98d135d127fcb
18dcbb0d6ce7434a76f8ebea40739e8eb5b14b78
Gyan
On 2021-04-01 18:48, Gyan Doshi wrote:
---
libavfilter/vf_find_rect.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index f9129cc140..b6f5a1be29 100644
--- a/libavfilter/vf_find_rect.c
+++ b/libavfilter/vf_find_rect.c
@@ -187,6 +187,7 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *in)
float best_score;
int best_x, best_y;
int i;
+ char buf[32];
foc->haystack_frame[0] = av_frame_clone(in);
for (i=1; imipmaps; i++) {
@@ -222,12 +223,15 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *in)
foc->last_x = best_x;
foc->last_y = best_y;
+ snprintf(buf, sizeof(buf), "%f", best_score);
+
av_frame_make_writable(in);
av_dict_set_int(>metadata, "lavfi.rect.w",
foc->obj_frame->width, 0);
av_dict_set_int(>metadata, "lavfi.rect.h",
foc->obj_frame->height, 0);
av_dict_set_int(>metadata, "lavfi.rect.x", best_x, 0);
av_dict_set_int(>metadata, "lavfi.rect.y", best_y, 0);
+ av_dict_set(>metadata, "lavfi.rect.score", buf, 0);
return ff_filter_frame(ctx->outputs[0], in);
}
___
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".
___
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".
Re: [FFmpeg-devel] [PATCH] web/documentation: Added my book (FFMPEG Quick Hacks) to list of FFmpeg books
On 2021-04-04 06:13, V Subhash [FFMPEG Quick Hacks] wrote: Also, there are many instructional resources available, both free and commercial, and it would be misleading to list only a few. Last year, I suggested all recent books to be listed but there was no response. http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262634.html After I made the ebook free, I contacted Lou Logan. He mentioned that (he is not with FFmpeg anymore but that) FFmpeg.org did not want to make assumptions on other authors. Quoting him: I know you did this before, but if I recall correctly the main problem was that your previous patch included many other books. We did not know if those other authors wanted their books to be listed. (I assume they would, but FFmpeg does not like to make assumptions on other peoples behalf.) I'm talking about starting a page on the wiki and listing all books *there*. No patch required. Regards, Gyan ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, Apr 3, 2021 at 16:53 Michael Niedermayer wrote: > On Sat, Apr 03, 2021 at 02:19:58PM +0800, Linjie Fu wrote: > > On Sat, Apr 3, 2021 at 09:10 Zane van Iperen > wrote: > > > > > > > > > > > On 2/4/21 8:34 pm, RADSL wrote: > > > > > > > > On 4/2/2021 2:59 AM, Michael Niedermayer wrote: > > > >> Hi all > > > >> > > > >> We still need to choose the name for 4.4 > > > >> previous unused suggestions where: > > > >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > > > Viterbi, Darwin > > > >> > > > >> Feel free to reply with name suggestions > > > >> If theres a tie then i will randomly pick amongth the tied, i assume > > > all previous > > > >> suggestions where suggested exactly once already. > > > >> > > > >> I plan to make the release today or tomorrow unless major bugfixes > are > > > >> still pending. I probably wont have time sunday / monday for making > the > > > >> release > > > >> > > > >> Thanks > > > >> > > > >> > > > > version 4.4 Plandemic > > > > > > Absolutely +1 Plandemic > > > > > > Plandemic sounds cool. > > it does until you google what it refers too > > Do the people voting for that want FFmpeg to be associated with the > movie(s) ? > Misunderstood the word and its usage. Sorry for the misunderstanding, no offense from my side. ___ 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".
Re: [FFmpeg-devel] [PATCH] web/documentation: Added my book (FFMPEG Quick Hacks) to list of FFmpeg books
> Also, there are many instructional resources available, both free and > commercial, and it would be misleading to list only a few. Last year, I suggested all recent books to be listed but there was no response. http://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262634.html After I made the ebook free, I contacted Lou Logan. He mentioned that (he is not with FFmpeg anymore but that) FFmpeg.org did not want to make assumptions on other authors. Quoting him: > I know you did this before, but if I recall correctly the main problem was > that your > previous patch included many other books. We did not know if those other > authors > wanted their books to be listed. (I assume they would, but FFmpeg does not > like > to make assumptions on other peoples behalf.) ___ 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".
[FFmpeg-devel] [PATCH v4] avformat/utils: add helper functions to retrieve index entries from an AVStream
Signed-off-by: James Almer
---
Now using the avformat_ prefix as Anton requested. I forgot about it when i
made v3.
libavformat/avformat.h | 39 +++
libavformat/utils.c| 27 +++
2 files changed, 66 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6a9b09160c..a1e87ef891 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2767,6 +2767,45 @@ int av_find_default_stream_index(AVFormatContext *s);
*/
int av_index_search_timestamp(AVStream *st, int64_t timestamp, int flags);
+/**
+ * Get the index entry count for the given AVStream.
+ *
+ * @param st stream
+ * @return the number of index entries in the stream
+ */
+int avformat_index_get_entries_count(AVStream *st);
+
+/**
+ * Get the AVIndexEntry corresponding to the given index.
+ *
+ * @param st Stream containing the requested AVIndexEntry.
+ * @param idx The desired index.
+ * @return A pointer to the requested AVIndexEntry if it exists, NULL
otherwise.
+ *
+ * @note The pointer returned by this function is only guaranteed to be valid
+ * until any function that could alter the stream or the AVFormatContext
+ * that cointains it is called.
+ */
+const AVIndexEntry *avformat_index_get_entry(AVStream *st, int idx);
+
+/**
+ * Get the AVIndexEntry corresponding to the given timestamp.
+ *
+ * @param st Stream containing the requested AVIndexEntry.
+ * @param timestamp Timestamp to retrieve the index entry for.
+ * @param flags If AVSEEK_FLAG_BACKWARD then the returned entry will
correspond
+ *to the timestamp which is <= the requested one, if
backward
+ *is 0, then it will be >=
+ *if AVSEEK_FLAG_ANY seek to any frame, only keyframes
otherwise.
+ * @return A pointer to the requested AVIndexEntry if it exists, NULL
otherwise.
+ *
+ * @note The pointer returned by this function is only guaranteed to be valid
+ * until any function that could alter the stream or the AVFormatContext
+ * that cointains it is called.
+ */
+const AVIndexEntry *avformat_index_get_entry_from_timestamp(AVStream *st,
+int64_t
wanted_timestamp,
+int flags);
/**
* Add an index entry into a sorted list. Update the entry if the list
* already contains it.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e9bf31e38b..942d7c8390 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2176,6 +2176,33 @@ int av_index_search_timestamp(AVStream *st, int64_t
wanted_timestamp, int flags)
wanted_timestamp, flags);
}
+int avformat_index_get_entries_count(AVStream *st)
+{
+return st->internal->nb_index_entries;
+}
+
+const AVIndexEntry *avformat_index_get_entry(AVStream *st, int idx)
+{
+if (idx < 0 || idx >= st->internal->nb_index_entries)
+return NULL;
+
+return >internal->index_entries[idx];
+}
+
+const AVIndexEntry *avformat_index_get_entry_from_timestamp(AVStream *st,
+int64_t
wanted_timestamp,
+int flags)
+{
+int idx = ff_index_search_timestamp(st->internal->index_entries,
+st->internal->nb_index_entries,
+wanted_timestamp, flags);
+
+if (idx < 0)
+return NULL;
+
+return >internal->index_entries[idx];
+}
+
static int64_t ff_read_timestamp(AVFormatContext *s, int stream_index, int64_t
*ppos, int64_t pos_limit,
int64_t (*read_timestamp)(struct
AVFormatContext *, int , int64_t *, int64_t ))
{
--
2.31.0
___
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".
[FFmpeg-devel] [PATCH] avutil/cpu: Use HW_NCPUONLINE to detect # of online CPUs with OpenBSD
avutil/cpu: Use HW_NCPUONLINE to detect # of online CPUs with OpenBSD
Signed-off-by: Brad Smith
---
libavutil/cpu.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 8e3576a1f3..9d249737df 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -291,6 +291,12 @@ int av_cpu_count(void)
DWORD_PTR proc_aff, sys_aff;
if (GetProcessAffinityMask(GetCurrentProcess(), _aff, _aff))
nb_cpus = av_popcount64(proc_aff);
+#elif HAVE_SYSCTL && defined(HW_NCPUONLINE)
+int mib[2] = { CTL_HW, HW_NCPUONLINE };
+size_t len = sizeof(nb_cpus);
+
+if (sysctl(mib, 2, _cpus, , NULL, 0) == -1)
+nb_cpus = 0;
#elif HAVE_SYSCTL && defined(HW_NCPU)
int mib[2] = { CTL_HW, HW_NCPU };
size_t len = sizeof(nb_cpus);
--
2.30.2
___
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".
Re: [FFmpeg-devel] [PATCH v2] atomics: Fix the win32 atomic_exchange function
On 4/3/2021 6:53 PM, Martin Storsjö wrote:
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
Changed to use PVOID.
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h
index bb8e6e7e15..28a627bfd3 100644
--- a/compat/atomics/win32/stdatomic.h
+++ b/compat/atomics/win32/stdatomic.h
@@ -96,7 +96,7 @@ do {\
atomic_load(object)
#define atomic_exchange(object, desired) \
-InterlockedExchangePointer(object, desired);
+InterlockedExchangePointer((PVOID volatile *)object, (PVOID)desired)
#define atomic_exchange_explicit(object, desired, order) \
atomic_exchange(object, desired)
Should be ok. Thanks.
___
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".
[FFmpeg-devel] [PATCH v2] atomics: Fix the win32 atomic_exchange function
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
Changed to use PVOID.
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h
index bb8e6e7e15..28a627bfd3 100644
--- a/compat/atomics/win32/stdatomic.h
+++ b/compat/atomics/win32/stdatomic.h
@@ -96,7 +96,7 @@ do {\
atomic_load(object)
#define atomic_exchange(object, desired) \
-InterlockedExchangePointer(object, desired);
+InterlockedExchangePointer((PVOID volatile *)object, (PVOID)desired)
#define atomic_exchange_explicit(object, desired, order) \
atomic_exchange(object, desired)
--
2.25.1
___
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".
Re: [FFmpeg-devel] [PATCH] atomics: Fix the win32 atomic_exchange function
On 4/3/2021 6:19 PM, Martin Storsjö wrote:
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h
index bb8e6e7e15..9e91e27262 100644
--- a/compat/atomics/win32/stdatomic.h
+++ b/compat/atomics/win32/stdatomic.h
@@ -96,7 +96,7 @@ do {\
atomic_load(object)
#define atomic_exchange(object, desired) \
-InterlockedExchangePointer(object, desired);
+InterlockedExchangePointer((void *volatile *)object, (void *)desired)
nit: PVOID instead of void*, same as elsewhere in this file, and how
it's documented in the official docs.
#define atomic_exchange_explicit(object, desired, order) \
atomic_exchange(object, desired)
___
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".
[FFmpeg-devel] [PATCH] atomics: Fix the win32 atomic_exchange function
This fixes building with MSVC after
a2a38b160620d91bc3f895dadc4501c589998b9c.
Remove the stray semicolon, and add casts for the input argument
(which is an intptr_t*) to the right type (void *volatile *).
---
compat/atomics/win32/stdatomic.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/atomics/win32/stdatomic.h b/compat/atomics/win32/stdatomic.h
index bb8e6e7e15..9e91e27262 100644
--- a/compat/atomics/win32/stdatomic.h
+++ b/compat/atomics/win32/stdatomic.h
@@ -96,7 +96,7 @@ do {\
atomic_load(object)
#define atomic_exchange(object, desired) \
-InterlockedExchangePointer(object, desired);
+InterlockedExchangePointer((void *volatile *)object, (void *)desired)
#define atomic_exchange_explicit(object, desired, order) \
atomic_exchange(object, desired)
--
2.25.1
___
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".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_nlmeans_opencl: making filter independent of bit depth
Em sáb., 3 de abr. de 2021 às 19:26, Mark Thompson escreveu:
>
> On 21/03/2021 23:22, Lucas Clemente Vella wrote:
> > This filter originally quantized OpenCL float images fetchs in 256 levels,
> > and computed the integral image of squared differences in 32 bit integers.
> >
> > This had two consequences:
> > 1) it could overflow if the image resolution was big enough (I got overflows
> > in a 4K video);
> > 2) it dropped precision from bit depths higher than 8 bits.
> >
> > Now the integral image is computed with float values in range [0, 1],
> > instead
> > of integers in range [0, 255] (then squared), so there is no longer the risk
> > of overflow.
> >
> > And even with the accumulated floating point error over the integral image,
> > the resulting difference between this float implementation and an
> > experimental
> > uint64 implementation with 65535 quantization levels is less than 0.08%
> > on the worst difference (per component), and less than 0.002% on average.
> > For
> > reference, the smallest variation possible on a 10-bit quantization is
> > 0.098%
> > of the total intensity. This was tested on a 4K frame from an 10-bit source.
>
> Does the sum actually avoid floating-point error beyond simple rounding?
>
> Given only 23 bits of precision, it looks like there is a danger of losing
> things by adding a set of small numbers to a large number and the large
> number being unchanged.
I think it might, but I think the risk of affecting visibly the final
image is too small
given the performance benefit of this float4 version compared to the
ulong4 version
(my other patch). The image integral will still be a good enough approximation,
and the float4 version is twice as fast as the ulong4 version.
> >
> > Signed-off-by: Lucas Clemente Vella
> > ---
> > libavfilter/opencl/nlmeans.cl | 31 ++
> > libavfilter/vf_nlmeans_opencl.c | 34 +
> > 2 files changed, 19 insertions(+), 46 deletions(-)
> >
> > diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
> > index 72bd681fd6..6d78a41e46 100644
> > --- a/libavfilter/opencl/nlmeans.cl
> > +++ b/libavfilter/opencl/nlmeans.cl
> > @@ -20,7 +20,7 @@ const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> > CLK_ADDRESS_CLAMP_TO_EDGE |
> > CLK_FILTER_NEAREST);
> >
> > -kernel void horiz_sum(__global uint4 *integral_img,
> > +kernel void horiz_sum(__global float4 *integral_img,
> > __read_only image2d_t src,
> > int width,
> > int height,
> > @@ -31,7 +31,7 @@ kernel void horiz_sum(__global uint4 *integral_img,
> > int y = get_global_id(0);
> > int work_size = get_global_size(0);
> >
> > -uint4 sum = (uint4)(0);
> > +float4 sum = 0.0;
>
> Surprise double.
>
> > float4 s2;
> > for (int i = 0; i < width; i++) {
> > float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
> > @@ -39,28 +39,25 @@ kernel void horiz_sum(__global uint4 *integral_img,
> > s2.y = read_imagef(src, sampler, (int2)(i + dx.y, y + dy.y)).x;
> > s2.z = read_imagef(src, sampler, (int2)(i + dx.z, y + dy.z)).x;
> > s2.w = read_imagef(src, sampler, (int2)(i + dx.w, y + dy.w)).x;
> > -sum += convert_uint4((s1 - s2) * (s1 - s2) * 255 * 255);
> > +sum += (s1 - s2) * (s1 - s2);
> > integral_img[y * width + i] = sum;
> > }
> > }
> >
> > -kernel void vert_sum(__global uint4 *integral_img,
> > - __global int *overflow,
> > +kernel void vert_sum(__global float4 *integral_img,
> >int width,
> >int height)
> > {
> > int x = get_global_id(0);
> > -uint4 sum = 0;
> > +float4 sum = 0;
>
> Please write floats as floats (0.0f), even if the implicit conversion is
> correct.
>
> > for (int i = 0; i < height; i++) {
> > -if (any((uint4)UINT_MAX - integral_img[i * width + x] < sum))
> > -atomic_inc(overflow);
> > integral_img[i * width + x] += sum;
> > sum = integral_img[i * width + x];
> > }
> > }
> >
> > kernel void weight_accum(global float *sum, global float *weight,
> > - global uint4 *integral_img, __read_only image2d_t
> > src,
> > + global float4 *integral_img, __read_only
> > image2d_t src,
> >int width, int height, int p, float h,
> >int4 dx, int4 dy)
> > {
> > @@ -75,16 +72,16 @@ kernel void weight_accum(global float *sum, global
> > float *weight,
> > int y = get_global_id(1);
> > int4 xoff = x + dx;
> > int4 yoff = y + dy;
> > -uint4 a = 0, b = 0, c = 0, d = 0;
> > -uint4 src_pix = 0;
> > +float4 a = 0, b = 0, c = 0, d = 0;
> > +float4 src_pix = 0;
> >
> > // out-of-bounding-box?
> > int
Re: [FFmpeg-devel] Hardware purchase request
Apr 3, 2021, 20:12 by mich...@niedermayer.cc: > On Sat, Apr 03, 2021 at 03:01:16PM +0200, Lynne wrote: > >> Apr 2, 2021, 23:28 by mich...@niedermayer.cc: >> >> > On Mon, Mar 29, 2021 at 11:03:16PM +0300, Jan Ekström wrote: >> > >> > IMO some of this list is quite reasonable like a 1TB NVME, then iam not >> > sure why you need a 2nd one. That can be needed of course but its not clear >> > from just the list. But really i dont want to "critique" the list, it just >> > overall feels like there was a misunderstanding and iam happy to approve >> > a machiene in the 2-3k range or also higher if its explained why its needed >> > for FFmpeg >> > >> > and sorry for my late reply >> > >> >> By removing the screen (could borrow one for now), half the RAM, the second >> SSD, >> and changing the motherboard, I can get this down to 4400 EUR. >> Unfortunately, the CPU and GPU constitute a large amount of the sum and not >> even downgrading them to a 6800 and a 5900 helps, in fact both of those are >> completely out of stock wherever I checked, since they used to be cheaper. >> So now there's mostly only the higher end options left, if at all. >> I could probably change the RAM to save on an additional 100 EUR, but >> I don't see this going below 4000 EUR. >> In the past you could probably have gotten away with much less, but like I >> said, >> there's a chip shortage going on where everything is much more expensive >> than it otherwise should have been, if it's even available in stock. >> > > do we have some idea about when the shortage will be resolved ? > I expect it to end a few months after the pandemic ends. And I wish I knew when that would happen, if it will even happen at all. I searched some more and swapped for a Rocket Lake chip, which I managed to find, which also allowed me to swap the motherboard for one cheaper still, so I managed to bring the price down to 3900EUR. The main bulk of the cost is still the GPU, which goes for nearly twice the price of its release. Sadly, coin miners are keeping demand and therefore cost up. It's been like this for many years, or so I hear. If someone from AMD is listening and wants to help out like what happened some years ago, it would be most welcome. But as far as I know, no one in the FFmpeg + VLC community has any contacts in AMD at all these days. > and what the cost difference is ? > and also what impact that has on your work, if we wait, could you > work on something else that you enjoy and that is useful in the meantime ? > I cannot really optimize our Vulkan code at all, nor get important features like Vulkan API interoperability working (because my Intel GPU does not support the necessary extensions), nor work on improving AV1 VAAPI decoding, or for that matter, work on much involving video on my weak old laptop. And if our Vulkan code breaks, which has happened, I cannot test it at all, since I can't use it. And if AMD finally release the video decoding extension, I wouldn't be able to write support for it or help out with driver development. I'd also like to write some AVX512 assembly beyond the most basic extra vector register usage. Finally, I can sort of optimize my assembly for modern machines, but nothing really beats optimizing for the actual machine you're running on. In the meanwhile I'm working on rewriting our AAC and Opus encoders, as well as writing assembly for lavu/tx, which can't keep me busy for more than a few months if I can keep up the pace. ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
Hey code of conduct committee, can we ban this person? Kieran Sent from my mobile device On Sat, 3 Apr 2021, 22:06 RADSL, wrote: > > On 4/3/2021 12:47 PM, Kieran Kunhya wrote: > > Who are you and what on earth are you talking about? > > > > Why on earth is it appropriate to name an ffmpeg release after a disease > > that has killed millions? > > > > Kieran > > > > Sent from my mobile device > > > Is it appropriate to make sport shoes with human blood? > ___ > 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". ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On 4/3/2021 12:47 PM, Kieran Kunhya wrote: Who are you and what on earth are you talking about? Why on earth is it appropriate to name an ffmpeg release after a disease that has killed millions? Kieran Sent from my mobile device Is it appropriate to make sport shoes with human blood? ___ 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".
Re: [FFmpeg-devel] FFmpeg 4.4
On Sat, Mar 20, 2021 at 01:17:53AM +0100, Michael Niedermayer wrote: > On Fri, Mar 19, 2021 at 05:07:00PM +0100, Michael Niedermayer wrote: > > On Wed, Mar 17, 2021 at 04:23:50PM -0300, James Almer wrote: > > > On 3/13/2021 8:29 AM, Michael Niedermayer wrote: > > > > On Wed, Mar 10, 2021 at 10:06:49AM -0300, James Almer wrote: > > > > > On 3/10/2021 7:37 AM, Michael Niedermayer wrote: > > > > > > On Tue, Mar 09, 2021 at 05:55:55PM -0300, James Almer wrote: > > > > > > > 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 > > > > > > > now, that i want in 4.4 in order for them to be present in the > > > > > > > last release > > > > > > > using the current major library versions. This is so users have a > > > > > > > good > > > > > > > amount of time to notice them and adapt their code. > > > > > > > It's not be as nice if they start noticing any new deprecations > > > > > > > introduced > > > > > > > today in a release made several months from now. > > > > > > > > > > > > > > These are "deprecate av_init_packet() and sizeof(AVPacket) as > > > > > > > part of the > > > > > > > ABI", > > > > > > > > It seems this is still missing > > > > > > > > > > > > > > > "avutil/buffer: change public function and struct size parameter > > > > > > > types > > > > > > > to size_t", and > > > > > > > > I see several 4 "size parameter type to size_t" commits in git now so > > > > these > > > > seem applied > > > > > > > > > > > > > > > "avcodec: add a get_encoder_buffer() callback to > > > > > > > AVCodecContext". > > > > > > > > This was applied as 6e7e3a3820f0888ff92d6be44f40ff733bcce874 > > > > > > > > So it seems only one blocker is left for making the release branch > > > > > > > > If thats incorrect someone please correct me! > > > > > > > > thx > > > > > > All three sets were pushed, so nothing else from me. > > > > ok so i will make the branch soon. > > bug fixes can be backported anyway ... > > release/4.4 branched > please backport all security relevant bugfixes which you push to master! > and feel free to backport any other bugfixes > > I plan to make the 4.4 release in about a week but that time might slip > due to there being new malloc failure related bugs reported by cispa daily I intended to do the release today but multiple things seem to be still worked on that being a png regression, cispa / mpegvideo crashes. Also an extra day or 2 for the last minute cfhd fix probably isnt a bad idea either. so it feels like unwise to rush this today. Sadly i have no time tomorrow and monday. Will try to make the release in a few days thus Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
Who are you and what on earth are you talking about? Why on earth is it appropriate to name an ffmpeg release after a disease that has killed millions? Kieran Sent from my mobile device On Sat, 3 Apr 2021, 20:25 RADSL, wrote: > > On 4/3/2021 8:11 AM, Derek Buitenhuis wrote: > > On 03/04/2021 11:19, Jean-Baptiste Kempf wrote: > >> This is Internet and social networks in 2021. > >> It WILL be taken in the wrong way. > >> > >> Do NOT use anything political or related to the news in naming. Never > Ever. It might be badly taken, but mostly you have NO idea how it will be > taken in the future… > > Agree. > > > > Frankly using such a name is disgusting and offensive. > > > > It's not a funny """joke""". People are dead. > > > > This is the exact kind of BS unfunny "humour" (giant quotes) that > > people look down a the FOSS community for, and with good reason. > > > > - Derek > > > Frankly using such a name is disgusting and offensive > ??? > > > It's not a funny """joke""" > it's a an homage, nothing else. if you take it as a "joke", it's your > point of view only. > > > This is the exact kind of BS unfunny "humour" > who said it was humour? again it's only your point of view. > > only those who are blind cannot see the reality. and the reality is more > people are dying from political decisions today. > and I'm sorry to open this debate, but it concerns all of us since it > affects all of us, even for thos who don't watch TV. > ___ > 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_nlmeans_opencl: making filter independent of bit depth
On 21/03/2021 23:22, Lucas Clemente Vella wrote:
This filter originally quantized OpenCL float images fetchs in 256 levels,
and computed the integral image of squared differences in 32 bit integers.
This had two consequences:
1) it could overflow if the image resolution was big enough (I got overflows
in a 4K video);
2) it dropped precision from bit depths higher than 8 bits.
Now the integral image is computed with float values in range [0, 1], instead
of integers in range [0, 255] (then squared), so there is no longer the risk
of overflow.
And even with the accumulated floating point error over the integral image,
the resulting difference between this float implementation and an experimental
uint64 implementation with 65535 quantization levels is less than 0.08%
on the worst difference (per component), and less than 0.002% on average. For
reference, the smallest variation possible on a 10-bit quantization is 0.098%
of the total intensity. This was tested on a 4K frame from an 10-bit source.
Does the sum actually avoid floating-point error beyond simple rounding?
Given only 23 bits of precision, it looks like there is a danger of losing
things by adding a set of small numbers to a large number and the large number
being unchanged.
Signed-off-by: Lucas Clemente Vella
---
libavfilter/opencl/nlmeans.cl | 31 ++
libavfilter/vf_nlmeans_opencl.c | 34 +
2 files changed, 19 insertions(+), 46 deletions(-)
diff --git a/libavfilter/opencl/nlmeans.cl b/libavfilter/opencl/nlmeans.cl
index 72bd681fd6..6d78a41e46 100644
--- a/libavfilter/opencl/nlmeans.cl
+++ b/libavfilter/opencl/nlmeans.cl
@@ -20,7 +20,7 @@ const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
CLK_ADDRESS_CLAMP_TO_EDGE |
CLK_FILTER_NEAREST);
-kernel void horiz_sum(__global uint4 *integral_img,
+kernel void horiz_sum(__global float4 *integral_img,
__read_only image2d_t src,
int width,
int height,
@@ -31,7 +31,7 @@ kernel void horiz_sum(__global uint4 *integral_img,
int y = get_global_id(0);
int work_size = get_global_size(0);
-uint4 sum = (uint4)(0);
+float4 sum = 0.0;
Surprise double.
float4 s2;
for (int i = 0; i < width; i++) {
float s1 = read_imagef(src, sampler, (int2)(i, y)).x;
@@ -39,28 +39,25 @@ kernel void horiz_sum(__global uint4 *integral_img,
s2.y = read_imagef(src, sampler, (int2)(i + dx.y, y + dy.y)).x;
s2.z = read_imagef(src, sampler, (int2)(i + dx.z, y + dy.z)).x;
s2.w = read_imagef(src, sampler, (int2)(i + dx.w, y + dy.w)).x;
-sum += convert_uint4((s1 - s2) * (s1 - s2) * 255 * 255);
+sum += (s1 - s2) * (s1 - s2);
integral_img[y * width + i] = sum;
}
}
-kernel void vert_sum(__global uint4 *integral_img,
- __global int *overflow,
+kernel void vert_sum(__global float4 *integral_img,
int width,
int height)
{
int x = get_global_id(0);
-uint4 sum = 0;
+float4 sum = 0;
Please write floats as floats (0.0f), even if the implicit conversion is
correct.
for (int i = 0; i < height; i++) {
-if (any((uint4)UINT_MAX - integral_img[i * width + x] < sum))
-atomic_inc(overflow);
integral_img[i * width + x] += sum;
sum = integral_img[i * width + x];
}
}
kernel void weight_accum(global float *sum, global float *weight,
- global uint4 *integral_img, __read_only image2d_t src,
+ global float4 *integral_img, __read_only image2d_t
src,
int width, int height, int p, float h,
int4 dx, int4 dy)
{
@@ -75,16 +72,16 @@ kernel void weight_accum(global float *sum, global float
*weight,
int y = get_global_id(1);
int4 xoff = x + dx;
int4 yoff = y + dy;
-uint4 a = 0, b = 0, c = 0, d = 0;
-uint4 src_pix = 0;
+float4 a = 0, b = 0, c = 0, d = 0;
+float4 src_pix = 0;
// out-of-bounding-box?
int oobb = (x - p) < 0 || (y - p) < 0 || (y + p) >= height || (x + p) >=
width;
-src_pix.x = (int)(255 * read_imagef(src, sampler, (int2)(xoff.x, yoff.x)).x);
-src_pix.y = (int)(255 * read_imagef(src, sampler, (int2)(xoff.y,
yoff.y)).x);
-src_pix.z = (int)(255 * read_imagef(src, sampler, (int2)(xoff.z,
yoff.z)).x);
-src_pix.w = (int)(255 * read_imagef(src, sampler, (int2)(xoff.w,
yoff.w)).x);
+src_pix.x = read_imagef(src, sampler, (int2)(xoff.x, yoff.x)).x;
+src_pix.y = read_imagef(src, sampler, (int2)(xoff.y, yoff.y)).x;
+src_pix.z = read_imagef(src, sampler, (int2)(xoff.z, yoff.z)).x;
+src_pix.w = read_imagef(src, sampler, (int2)(xoff.w, yoff.w)).x;
if (!oobb) {
a = integral_img[(y - p) * width + x -
Re: [FFmpeg-devel] 4.4 Release Name
On 4/3/2021 8:11 AM, Derek Buitenhuis wrote: On 03/04/2021 11:19, Jean-Baptiste Kempf wrote: This is Internet and social networks in 2021. It WILL be taken in the wrong way. Do NOT use anything political or related to the news in naming. Never Ever. It might be badly taken, but mostly you have NO idea how it will be taken in the future… Agree. Frankly using such a name is disgusting and offensive. It's not a funny """joke""". People are dead. This is the exact kind of BS unfunny "humour" (giant quotes) that people look down a the FOSS community for, and with good reason. - Derek > Frankly using such a name is disgusting and offensive ??? > It's not a funny """joke""" it's a an homage, nothing else. if you take it as a "joke", it's your point of view only. > This is the exact kind of BS unfunny "humour" who said it was humour? again it's only your point of view. only those who are blind cannot see the reality. and the reality is more people are dying from political decisions today. and I'm sorry to open this debate, but it concerns all of us since it affects all of us, even for thos who don't watch TV. ___ 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".
Re: [FFmpeg-devel] Hardware purchase request
On Sat, Apr 03, 2021 at 03:01:16PM +0200, Lynne wrote: > > > > Apr 2, 2021, 23:28 by mich...@niedermayer.cc: > > > On Mon, Mar 29, 2021 at 11:03:16PM +0300, Jan Ekström wrote: > > > > IMO some of this list is quite reasonable like a 1TB NVME, then iam not > > sure why you need a 2nd one. That can be needed of course but its not clear > > from just the list. But really i dont want to "critique" the list, it just > > overall feels like there was a misunderstanding and iam happy to approve > > a machiene in the 2-3k range or also higher if its explained why its needed > > for FFmpeg > > > > and sorry for my late reply > > > > By removing the screen (could borrow one for now), half the RAM, the second > SSD, > and changing the motherboard, I can get this down to 4400 EUR. > Unfortunately, the CPU and GPU constitute a large amount of the sum and not > even downgrading them to a 6800 and a 5900 helps, in fact both of those are > completely out of stock wherever I checked, since they used to be cheaper. > So now there's mostly only the higher end options left, if at all. > I could probably change the RAM to save on an additional 100 EUR, but > I don't see this going below 4000 EUR. > In the past you could probably have gotten away with much less, but like I > said, > there's a chip shortage going on where everything is much more expensive > than it otherwise should have been, if it's even available in stock. do we have some idea about when the shortage will be resolved ? and what the cost difference is ? and also what impact that has on your work, if we wait, could you work on something else that you enjoy and that is useful in the meantime ? > > I'll still likely have to do what I'll have to do to get the Vulkan code > ready for 5.0 > without any of this, so no hard feelings if any of you disagrees. > ___ > 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". -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] [PATCH v3] avformat/utils: add helper functions to retrieve index entries from an AVStream
Signed-off-by: James Almer
---
Now returning a pointer to the requested entry.
libavformat/avformat.h | 38 ++
libavformat/utils.c| 26 ++
2 files changed, 64 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 6a9b09160c..39371ea6d8 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2767,6 +2767,44 @@ int av_find_default_stream_index(AVFormatContext *s);
*/
int av_index_search_timestamp(AVStream *st, int64_t timestamp, int flags);
+/**
+ * Get the index entry count for the given AVStream.
+ *
+ * @param st stream
+ * @return the number of index entries in the stream
+ */
+int av_index_get_entries_count(AVStream *st);
+
+/**
+ * Get the AVIndexEntry corresponding to the given index.
+ *
+ * @param st Stream containing the requested AVIndexEntry.
+ * @param idx The desired index.
+ * @return A pointer to the requested AVIndexEntry if it exists, NULL
otherwise.
+ *
+ * @note The pointer returned by this function is only guaranteed to be valid
+ * until any function that could alter the stream or the AVFormatContext
+ * that cointains it is called.
+ */
+const AVIndexEntry *av_index_get_entry(AVStream *st, int idx);
+
+/**
+ * Get the AVIndexEntry corresponding to the given timestamp.
+ *
+ * @param st Stream containing the requested AVIndexEntry.
+ * @param timestamp Timestamp to retrieve the index entry for.
+ * @param flags If AVSEEK_FLAG_BACKWARD then the returned entry will
correspond
+ *to the timestamp which is <= the requested one, if
backward
+ *is 0, then it will be >=
+ *if AVSEEK_FLAG_ANY seek to any frame, only keyframes
otherwise.
+ *
+ * @note The pointer returned by this function is only guaranteed to be valid
+ * until any function that could alter the stream or the AVFormatContext
+ * that cointains it is called.
+ */
+const AVIndexEntry *av_index_get_entry_from_timestamp(AVStream *st, int64_t
wanted_timestamp,
+ int flags);
+
/**
* Add an index entry into a sorted list. Update the entry if the list
* already contains it.
diff --git a/libavformat/utils.c b/libavformat/utils.c
index e9bf31e38b..812237c57e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -2176,6 +2176,32 @@ int av_index_search_timestamp(AVStream *st, int64_t
wanted_timestamp, int flags)
wanted_timestamp, flags);
}
+int av_index_get_entries_count(AVStream *st)
+{
+return st->internal->nb_index_entries;
+}
+
+const AVIndexEntry *av_index_get_entry(AVStream *st, int idx)
+{
+if (idx < 0 || idx >= st->internal->nb_index_entries)
+return NULL;
+
+return >internal->index_entries[idx];
+}
+
+const AVIndexEntry *av_index_get_entry_from_timestamp(AVStream *st, int64_t
wanted_timestamp,
+ int flags)
+{
+int idx = ff_index_search_timestamp(st->internal->index_entries,
+st->internal->nb_index_entries,
+wanted_timestamp, flags);
+
+if (idx < 0)
+return NULL;
+
+return >internal->index_entries[idx];
+}
+
static int64_t ff_read_timestamp(AVFormatContext *s, int stream_index, int64_t
*ppos, int64_t pos_limit,
int64_t (*read_timestamp)(struct
AVFormatContext *, int , int64_t *, int64_t ))
{
--
2.31.0
___
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".
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: Keep track of which subbands have been read
On Sat, Apr 03, 2021 at 04:39:08PM +0200, Michael Niedermayer wrote:
> This avoids use of uninitialized data
> also several checks are inside the band reading code
> so it is important that it is run at least once
>
> Fixes: out of array accesses
> Fixes:
> 28209/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5684714694377472
> Fixes:
> 32124/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5425980681355264
> Fixes:
> 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4558757155700736
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/cfhd.c | 20
> libavcodec/cfhd.h | 1 +
> 2 files changed, 21 insertions(+)
> av_log(0,0, "TT %d ST %d\n", s->transform_type, s->sample_type);
> s->codebook = 0;
> @@ -919,6 +929,16 @@ finish:
> goto end;
> }
>
> +for (plane = 0; plane < s->planes; plane++) {
> +int o;
> +for (o = 0; o < 4 ; o++) {
> +if (!s->plane[plane].band[0][o].read_ok) {
> +ret = AVERROR_INVALIDDATA;
> +goto end;
> +}
> +}
> +}
ive replaced this hunk by:
@@ -919,6 +929,22 @@ finish:
goto end;
}
+for (plane = 0; plane < s->planes; plane++) {
+int o, level;
+
+for (level = 0; level < (s->transform_type == 0 ? DWT_LEVELS :
DWT_LEVELS_3D) ; level++) {
+if (s->transform_type == 2)
+if (level == 2 || level == 5)
+continue;
+for (o = !!level; o < 4 ; o++) {
+if (!s->plane[plane].band[level][o].read_ok) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+}
+}
+}
+
if (s->transform_type == 0 && s->sample_type != 1) {
for (plane = 0; plane < s->planes && !ret; plane++) {
/* level 1 */
so not just the first level is checked
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The smallest minority on earth is the individual. Those who deny
individual rights cannot claim to be defenders of minorities. - Ayn Rand
signature.asc
Description: PGP signature
___
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".
Re: [FFmpeg-devel] [PATCH 3/3] avfilter/find_rect: write score to metadata
Plan to push set tomorrow.
On 2021-04-01 18:48, Gyan Doshi wrote:
---
libavfilter/vf_find_rect.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index f9129cc140..b6f5a1be29 100644
--- a/libavfilter/vf_find_rect.c
+++ b/libavfilter/vf_find_rect.c
@@ -187,6 +187,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
float best_score;
int best_x, best_y;
int i;
+char buf[32];
foc->haystack_frame[0] = av_frame_clone(in);
for (i=1; imipmaps; i++) {
@@ -222,12 +223,15 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
foc->last_x = best_x;
foc->last_y = best_y;
+snprintf(buf, sizeof(buf), "%f", best_score);
+
av_frame_make_writable(in);
av_dict_set_int(>metadata, "lavfi.rect.w", foc->obj_frame->width, 0);
av_dict_set_int(>metadata, "lavfi.rect.h", foc->obj_frame->height, 0);
av_dict_set_int(>metadata, "lavfi.rect.x", best_x, 0);
av_dict_set_int(>metadata, "lavfi.rect.y", best_y, 0);
+av_dict_set(>metadata, "lavfi.rect.score", buf, 0);
return ff_filter_frame(ctx->outputs[0], in);
}
___
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".
[FFmpeg-devel] [PATCH] avcodec/wmavoice: Check operations that can fail
There might be segfaults on failure.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/wmavoice.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/wmavoice.c b/libavcodec/wmavoice.c
index e76807faa5..2cb4219b84 100644
--- a/libavcodec/wmavoice.c
+++ b/libavcodec/wmavoice.c
@@ -367,7 +367,7 @@ static av_cold void wmavoice_flush(AVCodecContext *ctx)
static av_cold int wmavoice_decode_init(AVCodecContext *ctx)
{
static AVOnce init_static_once = AV_ONCE_INIT;
-int n, flags, pitch_range, lsp16_flag;
+int n, flags, pitch_range, lsp16_flag, ret;
WMAVoiceContext *s = ctx->priv_data;
ff_thread_once(_static_once, wmavoice_init_static_data);
@@ -395,10 +395,11 @@ static av_cold int wmavoice_decode_init(AVCodecContext
*ctx)
s->spillover_bitsize = 3 + av_ceil_log2(ctx->block_align);
s->do_apf=flags & 0x1;
if (s->do_apf) {
-ff_rdft_init(>rdft, 7, DFT_R2C);
-ff_rdft_init(>irdft, 7, IDFT_C2R);
-ff_dct_init(>dct, 6, DCT_I);
-ff_dct_init(>dst, 6, DST_I);
+if ((ret = ff_rdft_init(>rdft, 7, DFT_R2C)) < 0 ||
+(ret = ff_rdft_init(>irdft, 7, IDFT_C2R)) < 0 ||
+(ret = ff_dct_init (>dct, 6,DCT_I)) < 0 ||
+(ret = ff_dct_init (>dst, 6,DST_I)) < 0)
+return ret;
ff_sine_window_init(s->cos, 256);
memcpy(>sin[255], s->cos, 256 * sizeof(s->cos[0]));
--
2.27.0
___
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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/mjpegdec: Fix leak in case of invalid external Huffman tables
On Sat, Apr 03, 2021 at 04:17:29PM +0200, Andreas Rheinhardt wrote: > When using external Huffman tables fails during init, the decoder > reverts back to using the default Huffman tables; and when doing so, > the current VLC tables leak because init_default_huffman_tables() > doesn't free them before overwriting them. > > Sample: > samples.ffmpeg.org/archive/all/avi+mjpeg+pcm_s16le++mjpeg-interlace.avi > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/mjpegdec.c | 1 + > 1 file changed, 1 insertion(+) probably ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/mjpegdec: Check initializing Huffman tables
On Sat, Apr 03, 2021 at 04:22:26PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> Is it actually intended that the decoder tries to use external Huffman
> tables purely based on the value of the option, even when there is no
> extradata at all (in which case init_get_bits() fails)?
>
> libavcodec/mjpegdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
> index 776797d35b..d0c933b52e 100644
> --- a/libavcodec/mjpegdec.c
> +++ b/libavcodec/mjpegdec.c
> @@ -154,7 +154,8 @@ av_cold int ff_mjpeg_decode_init(AVCodecContext *avctx)
> if (ff_mjpeg_decode_dht(s)) {
> av_log(avctx, AV_LOG_ERROR,
> "error using external huffman table, switching back to
> internal\n");
> -init_default_huffman_tables(s);
> +if ((ret = init_default_huffman_tables(s)) < 0)
> +return ret;
> }
> }
> if (avctx->field_order == AV_FIELD_BB) { /* quicktime icefloe 019 */
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
than the original author, trying to rewrite it will not make it better.
signature.asc
Description: PGP signature
___
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".
Re: [FFmpeg-devel] 4.4 Release Name
On 03/04/2021 11:19, Jean-Baptiste Kempf wrote: > This is Internet and social networks in 2021. > It WILL be taken in the wrong way. > > Do NOT use anything political or related to the news in naming. Never Ever. > It might be badly taken, but mostly you have NO idea how it will be taken in > the future… Agree. Frankly using such a name is disgusting and offensive. It's not a funny """joke""". People are dead. This is the exact kind of BS unfunny "humour" (giant quotes) that people look down a the FOSS community for, and with good reason. - Derek ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On 02/04/2021 12:05, Gyan Doshi wrote: > Rao +1 - Drek ___ 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".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: Check transform_type consistently
On Sat, Apr 03, 2021 at 04:39:06PM +0200, Michael Niedermayer wrote: > Fixes: out of array accesses > Fixes: > 29754/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6333598414274560 > Fixes: > 30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6298424511168512 > Fixes: > 30739/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5011292836462592 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/cfhd.c | 11 +-- > libavcodec/cfhd.h | 1 + > 2 files changed, 10 insertions(+), 2 deletions(-) I intend to apply this patchset soon. Also this patchset almost certainly does not fix every issue in CFHD, so if someone is searching for code to do a security review on. CFHD is likely an interresting candidate thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
> -Original Message- > From: ffmpeg-devel On Behalf Of > RADSL > Sent: Saturday, April 3, 2021 4:23 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] 4.4 Release Name > > > On 4/3/2021 6:02 AM, Lynne wrote: > > Apr 3, 2021, 12:19 by j...@videolan.org: > > > >> On Sat, 3 Apr 2021, at 11:50, Zane van Iperen wrote: > >> > >>> Personally no, I prefer "plandemic" for reasons given previously. > >>> > >>> However, Michael is right in saying that it could be taken the wrong way. > >>> > >> This is Internet and social networks in 2021. > >> It WILL be taken in the wrong way. > >> > >> Do NOT use anything political or related to the news in naming. Never > >> Ever. It might be badly taken, but mostly you have NO idea how it > >> will be taken in the future… > >> > >> Take a mathematician, a computer genius or a fantasy name. There are > >> plenty > >> > > > Michael is right indeed, > we are stuck with search engine A.I. sadly which will never know what is lie > and truth. > so why not version 4.4 Niedermayer? for all the nice work you did Michael? I don't know whether I have a vote with my tiny number of contributions, but my very first thought was: why honor dead persons instead of some that really deserve it in context of ffmpeg? +1 for Niedermayer softworkz ___ 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".
[FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: Keep track of which subbands have been read
This avoids use of uninitialized data
also several checks are inside the band reading code
so it is important that it is run at least once
Fixes: out of array accesses
Fixes:
28209/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5684714694377472
Fixes:
32124/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5425980681355264
Fixes:
30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-4558757155700736
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 20
libavcodec/cfhd.h | 1 +
2 files changed, 21 insertions(+)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 8bf910cde6..61e02999e9 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -221,6 +221,7 @@ static void free_buffers(CFHDContext *s)
int i, j;
for (i = 0; i < FF_ARRAY_ELEMS(s->plane); i++) {
+Plane *p = >plane[i];
av_freep(>plane[i].idwt_buf);
av_freep(>plane[i].idwt_tmp);
s->plane[i].idwt_size = 0;
@@ -230,6 +231,12 @@ static void free_buffers(CFHDContext *s)
for (j = 0; j < 10; j++)
s->plane[i].l_h[j] = NULL;
+
+for (j = 0; j < DWT_LEVELS_3D; j++)
+p->band[j][0].read_ok =
+p->band[j][1].read_ok =
+p->band[j][2].read_ok =
+p->band[j][3].read_ok = 0;
}
s->a_height = 0;
s->a_width = 0;
@@ -759,6 +766,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
lowpass_width * sizeof(*coeff_data));
}
+s->plane[s->channel_num].band[0][0].read_ok = 1;
+
av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients %d\n",
lowpass_width * lowpass_height);
}
@@ -891,6 +900,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
bytestream2_seek(, bytes, SEEK_CUR);
av_log(avctx, AV_LOG_DEBUG, "End subband coeffs %i extra %i\n",
count, count - expected);
+s->plane[s->channel_num].band[s->level][s->subband_num].read_ok =
1;
finish:
if (s->subband_num_actual != 255)
s->codebook = 0;
@@ -919,6 +929,16 @@ finish:
goto end;
}
+for (plane = 0; plane < s->planes; plane++) {
+int o;
+for (o = 0; o < 4 ; o++) {
+if (!s->plane[plane].band[0][o].read_ok) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+}
+}
+
if (s->transform_type == 0 && s->sample_type != 1) {
for (plane = 0; plane < s->planes && !ret; plane++) {
/* level 1 */
diff --git a/libavcodec/cfhd.h b/libavcodec/cfhd.h
index 4ec2a2ce8b..19e5c7cf03 100644
--- a/libavcodec/cfhd.h
+++ b/libavcodec/cfhd.h
@@ -114,6 +114,7 @@ typedef struct SubBand {
int width;
int a_height;
int height;
+int8_t read_ok;
} SubBand;
typedef struct Plane {
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 2/3] avcodec/cfhd: Require valid setup before Lowpass coefficients, BandHeader and BandSecondPass
Previously the code skipped all security checks when these where encountered
but prior data was incorrect.
Also replace an always true condition by an assert
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 39 +++
1 file changed, 27 insertions(+), 12 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index d719fbd65d..8bf910cde6 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -701,11 +701,18 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
coeff_data = s->plane[s->channel_num].subband[s->subband_num_actual];
/* Lowpass coefficients */
-if (tag == BitstreamMarker && data == 0xf0f && s->a_width &&
s->a_height) {
-int lowpass_height = s->plane[s->channel_num].band[0][0].height;
-int lowpass_width = s->plane[s->channel_num].band[0][0].width;
-int lowpass_a_height =
s->plane[s->channel_num].band[0][0].a_height;
-int lowpass_a_width = s->plane[s->channel_num].band[0][0].a_width;
+if (tag == BitstreamMarker && data == 0xf0f) {
+int lowpass_height, lowpass_width, lowpass_a_height,
lowpass_a_width;
+
+if (!s->a_width || !s->a_height) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+
+lowpass_height = s->plane[s->channel_num].band[0][0].height;
+lowpass_width = s->plane[s->channel_num].band[0][0].width;
+lowpass_a_height = s->plane[s->channel_num].band[0][0].a_height;
+lowpass_a_width = s->plane[s->channel_num].band[0][0].a_width;
if (lowpass_width < 3 ||
lowpass_width > lowpass_a_width) {
@@ -755,17 +762,25 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
av_log(avctx, AV_LOG_DEBUG, "Lowpass coefficients %d\n",
lowpass_width * lowpass_height);
}
-if ((tag == BandHeader || tag == BandSecondPass) &&
s->subband_num_actual != 255 && s->a_width && s->a_height) {
-int highpass_height =
s->plane[s->channel_num].band[s->level][s->subband_num].height;
-int highpass_width =
s->plane[s->channel_num].band[s->level][s->subband_num].width;
-int highpass_a_width =
s->plane[s->channel_num].band[s->level][s->subband_num].a_width;
-int highpass_a_height =
s->plane[s->channel_num].band[s->level][s->subband_num].a_height;
-int highpass_stride =
s->plane[s->channel_num].band[s->level][s->subband_num].stride;
+av_assert0(s->subband_num_actual != 255);
+if (tag == BandHeader || tag == BandSecondPass) {
+int highpass_height, highpass_width, highpass_a_width,
highpass_a_height, highpass_stride, a_expected;
int expected;
-int a_expected = highpass_a_height * highpass_a_width;
int level, run, coeff;
int count = 0, bytes;
+if (!s->a_width || !s->a_height) {
+ret = AVERROR_INVALIDDATA;
+goto end;
+}
+
+highpass_height =
s->plane[s->channel_num].band[s->level][s->subband_num].height;
+highpass_width =
s->plane[s->channel_num].band[s->level][s->subband_num].width;
+highpass_a_width =
s->plane[s->channel_num].band[s->level][s->subband_num].a_width;
+highpass_a_height =
s->plane[s->channel_num].band[s->level][s->subband_num].a_height;
+highpass_stride =
s->plane[s->channel_num].band[s->level][s->subband_num].stride;
+a_expected = highpass_a_height * highpass_a_width;
+
if (!got_buffer) {
av_log(avctx, AV_LOG_ERROR, "No end of header tag found\n");
ret = AVERROR(EINVAL);
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 1/3] avcodec/cfhd: Check transform_type consistently
Fixes: out of array accesses
Fixes:
29754/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6333598414274560
Fixes:
30519/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-6298424511168512
Fixes:
30739/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CFHD_fuzzer-5011292836462592
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/cfhd.c | 11 +--
libavcodec/cfhd.h | 1 +
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index 1f2ee853c1..d719fbd65d 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -233,6 +233,7 @@ static void free_buffers(CFHDContext *s)
}
s->a_height = 0;
s->a_width = 0;
+s->a_transform_type = INT_MIN;
}
static int alloc_buffers(AVCodecContext *avctx)
@@ -356,6 +357,7 @@ static int alloc_buffers(AVCodecContext *avctx)
}
}
+s->a_transform_type = s->transform_type;
s->a_height = s->coded_height;
s->a_width = s->coded_width;
s->a_format = s->coded_format;
@@ -655,7 +657,8 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
int *got_frame,
s->coded_height = s->a_height;
if (s->a_width != s->coded_width || s->a_height != s->coded_height
||
-s->a_format != s->coded_format) {
+s->a_format != s->coded_format ||
+s->transform_type != s->a_transform_type) {
free_buffers(s);
if ((ret = alloc_buffers(avctx)) < 0) {
free_buffers(s);
@@ -888,6 +891,7 @@ finish:
ff_thread_finish_setup(avctx);
if (!s->a_width || !s->a_height || s->a_format == AV_PIX_FMT_NONE ||
+s->a_transform_type == INT_MIN ||
s->coded_width || s->coded_height || s->coded_format !=
AV_PIX_FMT_NONE) {
av_log(avctx, AV_LOG_ERROR, "Invalid dimensions\n");
ret = AVERROR(EINVAL);
@@ -1381,12 +1385,14 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
if (pdst->plane[0].idwt_size != psrc->plane[0].idwt_size ||
pdst->a_format != psrc->a_format ||
pdst->a_width != psrc->a_width ||
-pdst->a_height != psrc->a_height)
+pdst->a_height != psrc->a_height ||
+pdst->a_transform_type != psrc->a_transform_type)
free_buffers(pdst);
pdst->a_format = psrc->a_format;
pdst->a_width = psrc->a_width;
pdst->a_height = psrc->a_height;
+pdst->a_transform_type = psrc->a_transform_type;
pdst->transform_type = psrc->transform_type;
pdst->progressive = psrc->progressive;
pdst->planes = psrc->planes;
@@ -1395,6 +1401,7 @@ static int update_thread_context(AVCodecContext *dst,
const AVCodecContext *src)
pdst->coded_width = pdst->a_width;
pdst->coded_height = pdst->a_height;
pdst->coded_format = pdst->a_format;
+pdst->transform_type = pdst->a_transform_type;
ret = alloc_buffers(dst);
if (ret < 0)
return ret;
diff --git a/libavcodec/cfhd.h b/libavcodec/cfhd.h
index 8ea91270cd..4ec2a2ce8b 100644
--- a/libavcodec/cfhd.h
+++ b/libavcodec/cfhd.h
@@ -165,6 +165,7 @@ typedef struct CFHDContext {
int a_width;
int a_height;
int a_format;
+int a_transform_type;
int bpc; // bits per channel/component
int channel_cnt;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity
On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote:
> Try this attached patch. I have not looked at all samples, as some allocate
> too much memory for my system.
> But this patch points where real bugs are, unlike yours patch which hides
> real bugs even more.
> cfhd.c |7 ++-
> cfhd.h |1 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
> eef066aa3ee9d301ae412809e0ca0bea8cee2c68
> 0001-avcodec-cfhd-fix-some-crashes-caused-by-excessive-fu.patch
> From fc4abcc0d0058ea8a7cd79ce26bfbcbed4cf5329 Mon Sep 17 00:00:00 2001
> From: Paul B Mahol
> Date: Thu, 1 Apr 2021 21:17:17 +0200
> Subject: [PATCH] avcodec/cfhd: fix some crashes caused by excessive fuzzing
>
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/cfhd.c | 7 ++-
> libavcodec/cfhd.h | 1 +
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> index 1f2ee853c1..e126eb6ac7 100644
> --- a/libavcodec/cfhd.c
> +++ b/libavcodec/cfhd.c
[...]
> @@ -244,6 +246,7 @@ static int alloc_buffers(AVCodecContext *avctx)
>
> if ((ret = ff_set_dimensions(avctx, s->coded_width, s->coded_height)) <
> 0)
> return ret;
> +avctx->coded_width = FFALIGN(s->coded_width, 64) + 256;
> avctx->pix_fmt = s->coded_format;
>
> ff_cfhddsp_init(>dsp, s->bpc, avctx->pix_fmt ==
> AV_PIX_FMT_BAYER_RGGB16);
[...]
> @@ -665,6 +669,7 @@ static int cfhd_decode(AVCodecContext *avctx, void *data,
> int *got_frame,
> ret = ff_set_dimensions(avctx, s->coded_width, s->coded_height);
> if (ret < 0)
> return ret;
> +avctx->coded_width = FFALIGN(s->coded_width, 64) + 256;
> if (s->cropped_height) {
> unsigned height = s->cropped_height << (avctx->pix_fmt ==
> AV_PIX_FMT_BAYER_RGGB16);
> if (avctx->height < height)
Please document why coded_width has this extra alignment and padding added
Also if these are still needed after the patchset i just posted then please
apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato
signature.asc
Description: PGP signature
___
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".
Re: [FFmpeg-devel] 4.4 Release Name
On 4/3/2021 6:02 AM, Lynne wrote: Apr 3, 2021, 12:19 by j...@videolan.org: On Sat, 3 Apr 2021, at 11:50, Zane van Iperen wrote: Personally no, I prefer "plandemic" for reasons given previously. However, Michael is right in saying that it could be taken the wrong way. This is Internet and social networks in 2021. It WILL be taken in the wrong way. Do NOT use anything political or related to the news in naming. Never Ever. It might be badly taken, but mostly you have NO idea how it will be taken in the future… Take a mathematician, a computer genius or a fantasy name. There are plenty Michael is right indeed, we are stuck with search engine A.I. sadly which will never know what is lie and truth. so why not version 4.4 Niedermayer? for all the nice work you did Michael? ___ 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".
[FFmpeg-devel] [PATCH 3/3] avcodec/mjpegdec: Fix leak in case ICC array allocations partially fail
If only one of the two arrays used for the ICC profile could be
successfully allocated, it might be overwritten and leak when
the next ICC entry is encountered. Fix this by using a common struct,
so that one has only one array to allocate.
Signed-off-by: Andreas Rheinhardt
---
See https://github.com/drewnoakes/metadata-extractor/issues/65 for a
sample.
libavcodec/mjpegdec.c | 28 +---
libavcodec/mjpegdec.h | 8 ++--
2 files changed, 19 insertions(+), 17 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index d0c933b52e..f3d9e99aab 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -2088,28 +2088,26 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
/* Allocate if this is the first APP2 we've seen. */
if (s->iccnum == 0) {
-s->iccdata = av_mallocz(nummarkers * sizeof(*(s->iccdata)));
-s->iccdatalens = av_mallocz(nummarkers *
sizeof(*(s->iccdatalens)));
-if (!s->iccdata || !s->iccdatalens) {
+if (!FF_ALLOCZ_TYPED_ARRAY(s->iccentries, nummarkers)) {
av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data
arrays\n");
return AVERROR(ENOMEM);
}
s->iccnum = nummarkers;
}
-if (s->iccdata[seqno - 1]) {
+if (s->iccentries[seqno - 1].data) {
av_log(s->avctx, AV_LOG_WARNING, "Duplicate ICC sequence
number\n");
goto out;
}
-s->iccdatalens[seqno - 1] = len;
-s->iccdata[seqno - 1] = av_malloc(len);
-if (!s->iccdata[seqno - 1]) {
+s->iccentries[seqno - 1].length = len;
+s->iccentries[seqno - 1].data = av_malloc(len);
+if (!s->iccentries[seqno - 1].data) {
av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data
buffer\n");
return AVERROR(ENOMEM);
}
-memcpy(s->iccdata[seqno - 1], align_get_bits(>gb), len);
+memcpy(s->iccentries[seqno - 1].data, align_get_bits(>gb), len);
skip_bits(>gb, len << 3);
len = 0;
s->iccread++;
@@ -2318,11 +2316,11 @@ static void reset_icc_profile(MJpegDecodeContext *s)
{
int i;
-if (s->iccdata)
+if (s->iccentries) {
for (i = 0; i < s->iccnum; i++)
-av_freep(>iccdata[i]);
-av_freep(>iccdata);
-av_freep(>iccdatalens);
+av_freep(>iccentries[i].data);
+av_freep(>iccentries);
+}
s->iccread = 0;
s->iccnum = 0;
@@ -2838,7 +2836,7 @@ the_end:
/* Sum size of all parts. */
for (i = 0; i < s->iccnum; i++)
-total_size += s->iccdatalens[i];
+total_size += s->iccentries[i].length;
sd = av_frame_new_side_data(frame, AV_FRAME_DATA_ICC_PROFILE,
total_size);
if (!sd) {
@@ -2848,8 +2846,8 @@ the_end:
/* Reassemble the parts, which are now in-order. */
for (i = 0; i < s->iccnum; i++) {
-memcpy(sd->data + offset, s->iccdata[i], s->iccdatalens[i]);
-offset += s->iccdatalens[i];
+memcpy(sd->data + offset, s->iccentries[i].data,
s->iccentries[i].length);
+offset += s->iccentries[i].length;
}
}
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 732aeab994..0d69d9101b 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -44,6 +44,11 @@
#define MAX_COMPONENTS 4
+typedef struct ICCEntry {
+uint8_t *data;
+intlength;
+} ICCEntry;
+
typedef struct MJpegDecodeContext {
AVClass *class;
AVCodecContext *avctx;
@@ -138,8 +143,7 @@ typedef struct MJpegDecodeContext {
const AVPixFmtDescriptor *pix_desc;
-uint8_t **iccdata;
-int *iccdatalens;
+ICCEntry *iccentries;
int iccnum;
int iccread;
--
2.27.0
___
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".
[FFmpeg-devel] [PATCH 2/3] avcodec/mjpegdec: Check initializing Huffman tables
Signed-off-by: Andreas Rheinhardt
---
Is it actually intended that the decoder tries to use external Huffman
tables purely based on the value of the option, even when there is no
extradata at all (in which case init_get_bits() fails)?
libavcodec/mjpegdec.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 776797d35b..d0c933b52e 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -154,7 +154,8 @@ av_cold int ff_mjpeg_decode_init(AVCodecContext *avctx)
if (ff_mjpeg_decode_dht(s)) {
av_log(avctx, AV_LOG_ERROR,
"error using external huffman table, switching back to
internal\n");
-init_default_huffman_tables(s);
+if ((ret = init_default_huffman_tables(s)) < 0)
+return ret;
}
}
if (avctx->field_order == AV_FIELD_BB) { /* quicktime icefloe 019 */
--
2.27.0
___
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".
[FFmpeg-devel] [PATCH 1/3] avcodec/mjpegdec: Fix leak in case of invalid external Huffman tables
When using external Huffman tables fails during init, the decoder
reverts back to using the default Huffman tables; and when doing so,
the current VLC tables leak because init_default_huffman_tables()
doesn't free them before overwriting them.
Sample:
samples.ffmpeg.org/archive/all/avi+mjpeg+pcm_s16le++mjpeg-interlace.avi
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mjpegdec.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 5583d2aa35..776797d35b 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -76,6 +76,7 @@ static int init_default_huffman_tables(MJpegDecodeContext *s)
int i, ret;
for (i = 0; i < FF_ARRAY_ELEMS(ht); i++) {
+ff_free_vlc(>vlcs[ht[i].class][ht[i].index]);
ret = ff_mjpeg_build_vlc(>vlcs[ht[i].class][ht[i].index],
ht[i].bits, ht[i].values,
ht[i].class == 1, s->avctx);
--
2.27.0
___
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".
Re: [FFmpeg-devel] [PATCH v2 02/18] cbs_h264: Add support for frame packing arrangement SEI messages
On 3/12/2021 7:56 PM, Mark Thompson wrote:
On 23/02/2021 16:39, James Almer wrote:
On 2/21/2021 4:51 PM, Mark Thompson wrote:
---
libavcodec/cbs_h264.h | 23
libavcodec/cbs_h2645.c | 6 +
libavcodec/cbs_h264_syntax_template.c | 39 +++
3 files changed, 68 insertions(+)
...
diff --git a/libavcodec/cbs_h264_syntax_template.c
b/libavcodec/cbs_h264_syntax_template.c
index 9587f33985..e03d41e47a 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -719,6 +719,45 @@ static int
FUNC(sei_recovery_point)(CodedBitstreamContext *ctx, RWContext *rw,
return 0;
}
+
+
+static int FUNC(sei_frame_packing_arrangement)
+ (CodedBitstreamContext *ctx, RWContext *rw,
+ H264RawSEIFramePackingArrangement *current, SEIMessageState *sei)
+{
+ int err;
+
+ HEADER("Frame Packing Arrangement");
+
+ ue(frame_packing_arrangement_id, 0, UINT32_MAX - 1);
+ flag(frame_packing_arrangement_cancel_flag);
+
+ if (!current->frame_packing_arrangement_cancel_flag) {
+ u(7, frame_packing_arrangement_type, 0, 7);
+ flag(quincunx_sampling_flag);
+ u(6, content_interpretation_type, 0, 2);
+ flag(spatial_flipping_flag);
+ flag(frame0_flipped_flag);
+ flag(field_views_flag);
+ flag(current_frame_is_frame0_flag);
+ flag(frame0_self_contained_flag);
+ flag(frame1_self_contained_flag);
+ if (!current->quincunx_sampling_flag &&
+ current->frame_packing_arrangement_type != 5) {
nit: maybe H264_SEI_FPA_TYPE_INTERLEAVE_TEMPORAL instead of 5.
The standard does say exactly "!= 5", so I prefer to keep to that. (It
would be nice if the H.2(6[456]|74) specs made better use of enum
constants, but we are stuck with what they actually do.)
Ok, LGTM then.
- Mark
___
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".
___
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".
Re: [FFmpeg-devel] 4.4 Release Name
Apr 3, 2021, 12:19 by j...@videolan.org: > On Sat, 3 Apr 2021, at 11:50, Zane van Iperen wrote: > >> Personally no, I prefer "plandemic" for reasons given previously. >> >> However, Michael is right in saying that it could be taken the wrong way. >> > > This is Internet and social networks in 2021. > It WILL be taken in the wrong way. > > Do NOT use anything political or related to the news in naming. Never Ever. > It might be badly taken, but mostly you have NO idea how it will be taken in > the future… > > Take a mathematician, a computer genius or a fantasy name. There are plenty > Had no idea Plandemic is what it is, thought it was just a pun. Changing my vote to Rao +1 Plandemic just no ___ 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".
Re: [FFmpeg-devel] Hardware purchase request
Apr 2, 2021, 23:28 by mich...@niedermayer.cc: > On Mon, Mar 29, 2021 at 11:03:16PM +0300, Jan Ekström wrote: > > IMO some of this list is quite reasonable like a 1TB NVME, then iam not > sure why you need a 2nd one. That can be needed of course but its not clear > from just the list. But really i dont want to "critique" the list, it just > overall feels like there was a misunderstanding and iam happy to approve > a machiene in the 2-3k range or also higher if its explained why its needed > for FFmpeg > > and sorry for my late reply > By removing the screen (could borrow one for now), half the RAM, the second SSD, and changing the motherboard, I can get this down to 4400 EUR. Unfortunately, the CPU and GPU constitute a large amount of the sum and not even downgrading them to a 6800 and a 5900 helps, in fact both of those are completely out of stock wherever I checked, since they used to be cheaper. So now there's mostly only the higher end options left, if at all. I could probably change the RAM to save on an additional 100 EUR, but I don't see this going below 4000 EUR. In the past you could probably have gotten away with much less, but like I said, there's a chip shortage going on where everything is much more expensive than it otherwise should have been, if it's even available in stock. I'll still likely have to do what I'll have to do to get the Vulkan code ready for 5.0 without any of this, so no hard feelings if any of you disagrees. ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
Jan Ekström wrote: >K. R. Rao +1 Yep, I changes my mind (thank you Michael for the hint!) +1 Rao -1 Plandemic Best regards, Reto ___ 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".
[FFmpeg-devel] [PATCH] avcodec/a64multienc: Don't use static buffers, fix potential races
render_charset() used static buffers that are always completely
initialized before every use, so that it is unnecessary for the
values in these arrays to be kept after leaving the function.
Given that this is not only unnecessary, but harmful due to the
possibility of data races if several instances of a64multi/a64multi5
run simultaneously these buffers have been replaced by ordinary buffers
on the stack (they are small enough for this).
Signed-off-by: Andreas Rheinhardt
---
Will apply this soon unless there are objections.
libavcodec/a64multienc.c | 11 +++
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/libavcodec/a64multienc.c b/libavcodec/a64multienc.c
index 55616c8524..91c89c87eb 100644
--- a/libavcodec/a64multienc.c
+++ b/libavcodec/a64multienc.c
@@ -107,13 +107,16 @@ static void render_charset(AVCodecContext *avctx, uint8_t
*charset,
uint8_t pix;
int lowdiff, highdiff;
int *best_cb = c->mc_best_cb;
-static uint8_t index1[256];
-static uint8_t index2[256];
-static uint8_t dither[256];
+uint8_t index1[256];
+uint8_t index2[256];
+uint8_t dither[256];
int i;
int distance;
-/* generate lookup-tables for dither and index before looping */
+/* Generate lookup-tables for dither and index before looping.
+ * This code relies on c->mc_luma_vals[c->mc_pal_size - 1] being
+ * the maximum of all the mc_luma_vals values and on the minimum
+ * being zero; this ensures that dither is properly initialized. */
i = 0;
for (a=0; a < 256; a++) {
if(i < c->mc_pal_size -1 && a == c->mc_luma_vals[i + 1]) {
--
2.27.0
___
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".
Re: [FFmpeg-devel] [PATCH] web/documentation: Added my book (FFMPEG Quick Hacks) to list of FFmpeg books
On 2021-04-03 15:35, FFmpegQuickHacks wrote: Added a third book to the existing list. The book information contains one link to the paperback seller and another link to my website where the free ebook can be viewed or downloaded. ** *The whole section 'Books about FFmpeg' is better off on the wiki* as it deals with external resources as opposed to most other sections at http://www.ffmpeg.org/documentation.html. It will be much easier to keep it up to date. Also, there are many instructional resources available, both free and commercial, and it would be misleading to list only a few. Feel free to create a page under '*Community Contributed Documentation'*at https://trac.ffmpeg.org/wiki and add your free ebook as an entry. Regards, Gyan * --- src/documentation |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/documentation b/src/documentation index 060ef06..2b708bc 100644 --- a/src/documentation +++ b/src/documentation @@ -130,6 +130,10 @@ describes various FFmpeg features and common tasks. http://book.chinaffmpeg.com;>FFmpeg Beginner's handbook Chinese Version by Steven Liu, describes FFmpeg common use method in Chinese, from command line to API usage. +https://www.amazon.com/FFMPEG-Quick-Hacks-collection-quick-reference/dp/B0892DHN53/;>FFMPEG Quick Hacks, + by V. Subhash, is a full-colour paperback published in 2020. It contains an extensive FFmpeg tutorial, + hack collection and quick reference. Its ePub ebook was made free in 2021 and can be downloaded from + http://www.vsubhash.in/ffmpeg-quick-hacks-book.html;>www.VSubhash.in. ___ 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".
Re: [FFmpeg-devel] [RFC] CFHD
Quoting Michael Niedermayer (2021-04-02 20:27:24) > Hi all > > CFHD currently has even with all fixes (ignoring ones with objections) > applied a null pointer > read and out of array write issue remaining. > > My patch which makes the header parsing more restrictive has an objection > against it. and the only other developer who recently worked on it > stated that he has no "time or motivation to deal with this and similar > issues" IMO any objection to a patch that does not include a clearly spelled out reason for the objection and/or an alternative solution should be ignored or regarded as spamming the ML. Especially when the patch addresses crashes or other security issues. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, 3 Apr 2021, at 11:50, Zane van Iperen wrote: > Personally no, I prefer "plandemic" for reasons given previously. > > However, Michael is right in saying that it could be taken the wrong way. This is Internet and social networks in 2021. It WILL be taken in the wrong way. Do NOT use anything political or related to the news in naming. Never Ever. It might be badly taken, but mostly you have NO idea how it will be taken in the future… Take a mathematician, a computer genius or a fantasy name. There are plenty -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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".
[FFmpeg-devel] [PATCH] web/documentation: Added my book (FFMPEG Quick Hacks) to list of FFmpeg books
Added a third book to the existing list. The book information contains one link to the paperback seller and another link to my website where the free ebook can be viewed or downloaded. --- src/documentation |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/src/documentation b/src/documentation index 060ef06..2b708bc 100644 --- a/src/documentation +++ b/src/documentation @@ -130,6 +130,10 @@ describes various FFmpeg features and common tasks. http://book.chinaffmpeg.com;>FFmpeg Beginner's handbook Chinese Version by Steven Liu, describes FFmpeg common use method in Chinese, from command line to API usage. +https://www.amazon.com/FFMPEG-Quick-Hacks-collection-quick-reference/dp/B0892DHN53/;>FFMPEG Quick Hacks, + by V. Subhash, is a full-colour paperback published in 2020. It contains an extensive FFmpeg tutorial, + hack collection and quick reference. Its ePub ebook was made free in 2021 and can be downloaded from + http://www.vsubhash.in/ffmpeg-quick-hacks-book.html;>www.VSubhash.in. -- 1.7.1 ___ 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".
[FFmpeg-devel] [PATCH] avcodec/rawdec: Free bitstream_buf
Signed-off-by: Andreas Rheinhardt --- This leak can be reproduced with mlv/M19-0333-cut.MLV from the FATE-suite; but it is currently only used for a demux test. Will apply soon. libavcodec/rawdec.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c index 1badb69180..d3756328ba 100644 --- a/libavcodec/rawdec.c +++ b/libavcodec/rawdec.c @@ -484,6 +484,7 @@ static av_cold int raw_close_decoder(AVCodecContext *avctx) RawVideoContext *context = avctx->priv_data; av_buffer_unref(>palette); +av_freep(>bitstream_buf); return 0; } -- 2.27.0 ___ 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".
Re: [FFmpeg-devel] Hardware purchase request
On Sat, Apr 3, 2021 at 10:58 AM Hendrik Leppkes wrote: > On Sat, Apr 3, 2021 at 10:24 AM Michael Niedermayer > wrote: > > > > All that said, i shouldnt have commented about the SSD, my concern is > more > > the overall cost. over 6k€ feels rather alot to me. For example my most > > expensive box i think was less than half that and my subjective oppinion > is > > that mine is more than fast enough for my work on FFmpeg. > > > > I agree with that. Much less is actually necessary for development. > > By Lynne's own request, the selection "spared no expense" on the > primary argument that we have the money, not that its actually needed > for development. > I don't think that's a sound argument for spending community money. We > should be buying what's needed, not what we can just because there are > funds available. > I disagree, lot of potential is wasted on discussion like this. While FFmpeg is slowly dying. > > - Hendrik > ___ > 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". ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, Apr 3, 2021 at 11:36 AM Jan Ekström wrote: > On Fri, Apr 2, 2021 at 12:59 PM Michael Niedermayer > wrote: > > > > Hi all > > > > We still need to choose the name for 4.4 > > previous unused suggestions where: > > Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > Viterbi, Darwin > > > > Feel free to reply with name suggestions > > If theres a tie then i will randomly pick amongth the tied, i assume all > previous > > suggestions where suggested exactly once already. > > > > I plan to make the release today or tomorrow unless major bugfixes are > > still pending. I probably wont have time sunday / monday for making the > > release > > > > Thanks > > > > K. R. Rao +1 > > I would refrain from direct references to the recent (and in some > places still ongoing) pandemic. > > Mr. Miser seems best fit. ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On 3/4/21 7:17 pm, Kieran Kunhya wrote: And you think "Corona" is better somehow? Kieran Sent from my mobile device Personally no, I prefer "plandemic" for reasons given previously. However, Michael is right in saying that it could be taken the wrong way. Perhaps, like Jan says, it's better to steer clear of Covid references... Michael, please change my vote to Rao. ___ 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".
Re: [FFmpeg-devel] [RFC] CFHD
On Fri, Apr 2, 2021 at 11:12 PM Michael Niedermayer wrote: > On Fri, Apr 02, 2021 at 10:22:27PM +0200, Paul B Mahol wrote: > > On Fri, Apr 2, 2021 at 10:14 PM Paul B Mahol wrote: > > > > > > > > > > > On Fri, Apr 2, 2021 at 8:28 PM Michael Niedermayer > > > > wrote: > > > > > >> Hi all > > >> > > >> CFHD currently has even with all fixes (ignoring ones with objections) > > >> applied a null pointer > > >> read and out of array write issue remaining. > > >> > > >> My patch which makes the header parsing more restrictive has an > objection > > >> against it. and the only other developer who recently worked on it > > >> stated that he has no "time or motivation to deal with this and > similar > > >> issues" > > >> > > >> Assuming no fix without objections is found. What do people prefer ? > > >> Delay the 4.4 release ? > > >> Apply all non objected fixes and mark CFHD as experimental ? > > >> Something else ? > > >> > > > > > > Start fixing professionally security issues. > > > > Am not going to do someone else job. > > Then you also should not object to someone else doing it in a way you > maybe dislike > I have already mentioned technical reasons why non-correct fixes are not correct way to fix issues. It have nothing to do with dislikes like you want to put. > > > > > > > > > > Also due to ignorance of giving needed equipment to other developer(s) > > what hardware do you need for FFmpeg ? you did not ask for any > > If its about someone elses request, i think theres a misunderstanding > there. > > Thanks > > > > I'm not really motivated to continue maintain any code. > > > > Why should person maintain code for no compensations, even symbolic ones. > > > > I'm really sad in all this situation, where some long time prolific and > > important contributors are simply being ignored. > > You are always being honest in one aspect, ignorance. > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The worst form of inequality is to try to make unequal things equal. > -- Aristotle > ___ > 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". ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Fri, Apr 2, 2021 at 12:59 PM Michael Niedermayer wrote: > > Hi all > > We still need to choose the name for 4.4 > previous unused suggestions where: > Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, > Darwin > > Feel free to reply with name suggestions > If theres a tie then i will randomly pick amongth the tied, i assume all > previous > suggestions where suggested exactly once already. > > I plan to make the release today or tomorrow unless major bugfixes are > still pending. I probably wont have time sunday / monday for making the > release > > Thanks > K. R. Rao +1 I would refrain from direct references to the recent (and in some places still ongoing) pandemic. Jan ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
Hello On 4/2/21 1:34 PM, RADSL wrote: > > version 4.4 Plandemic -1 Sounds too political. Vad ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
And you think "Corona" is better somehow? Kieran Sent from my mobile device On Sat, 3 Apr 2021, 11:15 Zane van Iperen, wrote: > > > On 3/4/21 7:04 pm, Kieran Kunhya wrote: > > You seriously think it's worth joking about the deaths of 3 million > people? > > > > Kieran > > > > Sent from my mobile device > > > > No, not at all - the joke is about the name "Plandemic", and how absurd it > is. > ___ > 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". ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, Apr 03, 2021 at 07:02:17PM +1000, Zane van Iperen wrote: > > > On 3/4/21 6:53 pm, Michael Niedermayer wrote: > > > > Plandemic sounds cool. > > > > it does until you google what it refers too > > > > Do the people voting for that want FFmpeg to be associated with the > > movie(s) ? > > I'd be inclined to think of it as more of a bit of light-hearted humour in > hard times rather than anything actually serious. and i would whole heartly agree with this. Except that this humor can be understood and used in multiply not funny ways. And on top of that could be damaging to FFmpeg > > If that's still too on-the-nose, how's "FFmpeg 4.4 - Corona"? ok, ive added that instead for your vote Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On 3/4/21 7:04 pm, Kieran Kunhya wrote: You seriously think it's worth joking about the deaths of 3 million people? Kieran Sent from my mobile device No, not at all - the joke is about the name "Plandemic", and how absurd it is. ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
You seriously think it's worth joking about the deaths of 3 million people? Kieran Sent from my mobile device On Sat, 3 Apr 2021, 11:02 Zane van Iperen, wrote: > > > On 3/4/21 6:53 pm, Michael Niedermayer wrote: > > >> Plandemic sounds cool. > > > > it does until you google what it refers too > > > > Do the people voting for that want FFmpeg to be associated with the > movie(s) ? > > I'd be inclined to think of it as more of a bit of light-hearted humour in > hard times rather than anything actually serious. > > If that's still too on-the-nose, how's "FFmpeg 4.4 - Corona"? > ___ > 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". ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On 3/4/21 6:53 pm, Michael Niedermayer wrote: Plandemic sounds cool. it does until you google what it refers too Do the people voting for that want FFmpeg to be associated with the movie(s) ? I'd be inclined to think of it as more of a bit of light-hearted humour in hard times rather than anything actually serious. If that's still too on-the-nose, how's "FFmpeg 4.4 - Corona"? ___ 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".
Re: [FFmpeg-devel] Hardware purchase request
On Sat, Apr 3, 2021 at 10:24 AM Michael Niedermayer wrote: > > All that said, i shouldnt have commented about the SSD, my concern is more > the overall cost. over 6k€ feels rather alot to me. For example my most > expensive box i think was less than half that and my subjective oppinion is > that mine is more than fast enough for my work on FFmpeg. > I agree with that. Much less is actually necessary for development. By Lynne's own request, the selection "spared no expense" on the primary argument that we have the money, not that its actually needed for development. I don't think that's a sound argument for spending community money. We should be buying what's needed, not what we can just because there are funds available. - Hendrik ___ 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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, Apr 03, 2021 at 02:19:58PM +0800, Linjie Fu wrote: > On Sat, Apr 3, 2021 at 09:10 Zane van Iperen wrote: > > > > > > > On 2/4/21 8:34 pm, RADSL wrote: > > > > > > On 4/2/2021 2:59 AM, Michael Niedermayer wrote: > > >> Hi all > > >> > > >> We still need to choose the name for 4.4 > > >> previous unused suggestions where: > > >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > > Viterbi, Darwin > > >> > > >> Feel free to reply with name suggestions > > >> If theres a tie then i will randomly pick amongth the tied, i assume > > all previous > > >> suggestions where suggested exactly once already. > > >> > > >> I plan to make the release today or tomorrow unless major bugfixes are > > >> still pending. I probably wont have time sunday / monday for making the > > >> release > > >> > > >> Thanks > > >> > > >> > > > version 4.4 Plandemic > > > > Absolutely +1 Plandemic > > > Plandemic sounds cool. it does until you google what it refers too Do the people voting for that want FFmpeg to be associated with the movie(s) ? Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I am the wisest man alive, for I know one thing, and that is that I know nothing. -- Socrates signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] Hardware purchase request
On Sat, Apr 03, 2021 at 09:39:13AM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2021-04-02 23:28:46) > > > > IMO some of this list is quite reasonable like a 1TB NVME, then iam not > > sure why you need a 2nd one. > > This specific part makes a lot of sense to me - you run them in a RAID1 > (mirror) configuration to guard against disk failure, with the secondary > benefit of higher read performance. I configure my machines that way > whenever possible. for a server (which needs 100% uptime) it makes sense. For a desktop system which one needs backups for anyway iam not sure. A failure of these disks is not a common occurance Fact is i never used raid1 on any of my desktop boxes and had i used it the main benefit probably would have been maybe less stress (which i think would be a valid justification). But then RAID1 only protects you from some failures about speed, these things are 7000MB/s is that a bottleneck ? iam using the previous generation of these samsung SSDs here and i certainly would not describe them as slow and needing 2x their bandwidth. but i have a better suggestion here. If its about speed, buy one, and if it in actual use is a bottleneck and affects work in a materially relevant way, request a 2nd one. All that said, i shouldnt have commented about the SSD, my concern is more the overall cost. over 6k€ feels rather alot to me. For example my most expensive box i think was less than half that and my subjective oppinion is that mine is more than fast enough for my work on FFmpeg. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB "I am not trying to be anyone's saviour, I'm trying to think about the future and not be sad" - Elon Musk signature.asc Description: PGP signature ___ 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".
[FFmpeg-devel] Re: [PATCH 2/7] lavc/pngdec: perform APNG blending in-place
Quoting James Almer (2021-04-02 16:54:47)
> On 4/2/2021 11:40 AM, Anton Khirnov wrote:
> > Saves an allocation+free and two frame copies per each frame.
> > ---
> > libavcodec/pngdec.c | 51 +
> > 1 file changed, 28 insertions(+), 23 deletions(-)
> >
> > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> > index 63c22063d9..095e4e86c2 100644
> > --- a/libavcodec/pngdec.c
> > +++ b/libavcodec/pngdec.c
> > @@ -1068,8 +1068,12 @@ static void handle_p_frame_png(PNGDecContext *s,
> > AVFrame *p)
> > static int handle_p_frame_apng(AVCodecContext *avctx, PNGDecContext *s,
> > AVFrame *p)
> > {
> > +uint8_t *dst= p->data[0];
> > +ptrdiff_t dst_stride = p->linesize[0];
> > +const uint8_t *src= s->last_picture.f->data[0];
> > +ptrdiff_t src_stride = s->last_picture.f->linesize[0];
> > +
> > size_t x, y;
> > -uint8_t *buffer;
> >
> > if (s->blend_op == APNG_BLEND_OP_OVER &&
> > avctx->pix_fmt != AV_PIX_FMT_RGBA &&
> > @@ -1089,26 +1093,32 @@ static int handle_p_frame_apng(AVCodecContext
> > *avctx, PNGDecContext *s,
> > if (ret < 0)
> > return ret;
> >
> > +src= s->last_picture.f->data[0];
> > +src_stride = s->last_picture.f->linesize[0];
>
> Is calling av_frame_make_writable(s->last_picture.f) valid at all?
> Shouldn't the frame's buffer be freed with ff_thread_release_buffer()?
> Especially if a non threading safe get_buffer2() callback was used.
>
> Considering you can't call ff_thread_get_buffer() at this point to get a
> new writable buffer to av_frame_copy() to, since this is long after
> ff_thread_finish_setup() was called, not sure what else could be done.
You're right, I guess making an unconditional copy local to this
function is the only way to make it compatible with thread safe
callbacks.
Will send a new patch.
--
Anton Khirnov
___
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".
Re: [FFmpeg-devel] Hardware purchase request
Quoting Michael Niedermayer (2021-04-02 23:28:46) > > IMO some of this list is quite reasonable like a 1TB NVME, then iam not > sure why you need a 2nd one. This specific part makes a lot of sense to me - you run them in a RAID1 (mirror) configuration to guard against disk failure, with the secondary benefit of higher read performance. I configure my machines that way whenever possible. -- Anton Khirnov ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Preserve disposition in the absence of language
stephen douglas: > ISO 639 language descriptors used by DVB are the 3 charecter variants hence > const char *language = lang && strlen(lang->value) >= 3 ? lang->value : > default_language;should beconst char *language = lang && strlen(lang->value) > > 3 ? lang->value : default_language; 1. Stop top-posting. 2. Are you even aware that strlen does not include the trailing \0? >On Saturday, 3 April 2021, 06:53:20 BST, Andreas Rheinhardt > wrote: > > Implements ticket #9113. > > Signed-off-by: Andreas Rheinhardt > --- ___ 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".
Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Preserve disposition in the absence of language
ISO 639 language descriptors used by DVB are the 3 charecter variants hence
const char *language = lang && strlen(lang->value) >= 3 ? lang->value :
default_language;should beconst char *language = lang && strlen(lang->value) >
3 ? lang->value : default_language;
On Saturday, 3 April 2021, 06:53:20 BST, Andreas Rheinhardt
wrote:
Implements ticket #9113.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mpegtsenc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 35c835c484..dbd3bb148a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -459,6 +459,8 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
AVStream *st = s->streams[i];
MpegTSWriteStream *ts_st = st->priv_data;
AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL,
0);
+ const char default_language[] = "und";
+ const char *language = lang && strlen(lang->value) >= 3 ? lang->value
: default_language;
enum AVCodecID codec_id = st->codecpar->codec_id;
if (s->nb_programs) {
@@ -598,16 +600,19 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
}
}
- if (lang) {
- char *p;
- char *next = lang->value;
+ if (language != default_language ||
+ st->disposition & (AV_DISPOSITION_CLEAN_EFFECTS |
+ AV_DISPOSITION_HEARING_IMPAIRED |
+ AV_DISPOSITION_VISUAL_IMPAIRED)) {
+ const char *p;
+ const char *next = language;
uint8_t *len_ptr;
*q++ = ISO_639_LANGUAGE_DESCRIPTOR;
len_ptr = q++;
*len_ptr = 0;
- for (p = lang->value; next && *len_ptr < 255 / 4 * 4; p = next
+ 1) {
+ for (p = next; next && *len_ptr < 255 / 4 * 4; p = next + 1) {
if (q - data > SECTION_LENGTH - 4) {
err = 1;
break;
@@ -637,10 +642,6 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
}
break;
case AVMEDIA_TYPE_SUBTITLE:
- {
- const char default_language[] = "und";
- const char *language = lang && strlen(lang->value) >= 3 ?
lang->value : default_language;
-
if (codec_id == AV_CODEC_ID_DVB_SUBTITLE) {
uint8_t *len_ptr;
int extradata_copied = 0;
@@ -715,7 +716,6 @@ static int mpegts_write_pmt(AVFormatContext *s,
MpegTSService *service)
*len_ptr = q - len_ptr - 1;
}
- }
break;
case AVMEDIA_TYPE_VIDEO:
if (stream_type == STREAM_TYPE_VIDEO_DIRAC) {
--
2.27.0
___
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".
___
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".
Re: [FFmpeg-devel] 4.4 Release Name
On Sat, Apr 3, 2021 at 09:10 Zane van Iperen wrote: > > > On 2/4/21 8:34 pm, RADSL wrote: > > > > On 4/2/2021 2:59 AM, Michael Niedermayer wrote: > >> Hi all > >> > >> We still need to choose the name for 4.4 > >> previous unused suggestions where: > >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, > Viterbi, Darwin > >> > >> Feel free to reply with name suggestions > >> If theres a tie then i will randomly pick amongth the tied, i assume > all previous > >> suggestions where suggested exactly once already. > >> > >> I plan to make the release today or tomorrow unless major bugfixes are > >> still pending. I probably wont have time sunday / monday for making the > >> release > >> > >> Thanks > >> > >> > > version 4.4 Plandemic > > Absolutely +1 Plandemic Plandemic sounds cool. ___ 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".
