Re: [FFmpeg-devel] [PATCH 3/4] avdevice/dshow: implement capabilities API
On Sun, Jun 6, 2021 at 6:15 AM Andreas Rheinhardt wrote: > Diederick C. Niehorster: > > See other mails: the bit of documentation in avdevice.h (lines > > 334--402) suggest the capabilities API is supposed to be used on an > > unopened device. It would make sense: probe the device for what it can > > do, decide what settings you want to use, then open device). In case > > of the dshow device, I think i cannot avoid potential false positives > > (entries in the query output that shouldn't be there) if the device is > > already opened. I'll experiment, perhaps this is only a theoretical > > worry. > > > And is the AVFormatContext that has been used for probing then supposed > to be reused for actually using the device? (You are calling > dshow_read_close() manually, but our cleanup functions typically only > clean up things that need to be freed; they e.g. don't reset (say) > ordinary ints to zero, although the code may rely upon this.) It is not supposed to, but does work. However, as user you still need to set the device options in the opts dict passed to avformat_open_input() even after narrowing down the format you want to use through the capabilities API. I'll document this. NB: reusing the AVFormatContext currently leaks a little bit of memory as, e.g., avformat_open_input() set url without checking and freeing if its already set. And maybe more. I'll just add a patch with my proposed API extension avformat_alloc_input_context() and needed extra checks to avformat_open_input(), so we can discuss it. All the best, Dee ___ 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/1] libavutil: Fix mips build
Check for sys/auxv.h because not all toolchains contain this header.
Fixes https://trac.ffmpeg.org/ticket/9138
Signed-off-by: Bernd Kuhls
---
configure| 2 ++
libavutil/mips/cpu.c | 6 +++---
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/configure b/configure
index 82367fd30d..b0154cb8b2 100755
--- a/configure
+++ b/configure
@@ -2161,6 +2161,7 @@ HEADERS_LIST="
opencv2_core_core_c_h
OpenGL_gl3_h
poll_h
+sys_auxv_h
sys_param_h
sys_resource_h
sys_select_h
@@ -6210,6 +6211,7 @@ check_func_headers VideoToolbox/VTCompressionSession.h
VTCompressionSessionPrepa
check_headers windows.h
check_headers X11/extensions/XvMClib.h
check_headers asm/types.h
+check_headers sys/auxv.h
# it seems there are versions of clang in some distros that try to use the
# gcc headers, which explodes for stdatomic
diff --git a/libavutil/mips/cpu.c b/libavutil/mips/cpu.c
index 59619d54de..4738104cdd 100644
--- a/libavutil/mips/cpu.c
+++ b/libavutil/mips/cpu.c
@@ -19,7 +19,7 @@
#include "libavutil/cpu.h"
#include "libavutil/cpu_internal.h"
#include "config.h"
-#if defined __linux__ || defined __ANDROID__
+#if (defined __linux__ || defined __ANDROID__) && defined(HAVE_SYS_AUXV_H)
#include
#include
#include
@@ -28,7 +28,7 @@
#include "libavutil/avstring.h"
#endif
-#if defined __linux__ || defined __ANDROID__
+#if (defined __linux__ || defined __ANDROID__) && defined(HAVE_SYS_AUXV_H)
#define HWCAP_LOONGSON_CPUCFG (1 << 14)
@@ -105,7 +105,7 @@ static int cpu_flags_cpuinfo(void)
int ff_get_cpu_flags_mips(void)
{
-#if defined __linux__ || defined __ANDROID__
+#if (defined __linux__ || defined __ANDROID__) && defined(HAVE_SYS_AUXV_H)
if (cpucfg_available())
return cpu_flags_cpucfg();
else
--
2.29.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 2/2] fftools/ffprobe: 240M matrix is not the same as BT.601
On Sun, 6 Jun 2021, Valerii Zapodovnikov wrote: I am sorry, what? It converts to 420 always? Wow? But you are right. Yes, because ffplay uses the default SDL renderer (may it be opengl/directx or anything else), and ffplay queries the hardware acccelerated pixel formats supported by that renderer (which usually is YUV420 and RGB, and SDL has a very limited list of pixel formats in the first place). -loglevel verbose shows you the texture format ffplay is using. is a problem that colors are wrong after YUV444 - > YUV420 -> RGB. It selects BT.709 matrix even if BT.601 matrix is requested, YUV444 -> YUV420 happens in swscale. YUV420 -> RGB happens in SDL using hardware acceleration. If swscale passes the orignial color matrix info properly to the YUV420 frame, then I am not sure where the bug can be, because ffplay directly checks AVFrame->color_range for setting the SDL conversion mode. Regards, Marton this can be fixed by "ffplay -vf scale=in_color_matrix=auto,format=gbrp" or just by using mpv. Maybe I need to further test VUI vs -movflags +write_colr vs what my samples use. ___ 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/2] fftools/ffprobe: 240M matrix is not the same as BT.601
AVFrame->color_range? But even if I were using full range file (I do not) that would force BT.601 full range matrix (that is JPEG matrix) and I have the opposite here, BT.709 is forced. I suppose the problem can be checked with simple printf of frame->colorspace with that sample that uses BT.601. This one: https://trac.ffmpeg.org/attachment/ticket/9167/2.mp4 It should be wrong at that point. Or use breakpoint in debugger. :) Also, BTW, Nvidia drivers windows 10, what is matrix used for 4K YCbCr formats by default? Is it already BT.709? Because xvYCC can be both BT.601 and BT.709 (but it is only limited range, even if full is set by mistake, see latest "ANSI/CTA-861-H") and sYCC with selectable quantisation uses BT.601 even on 4K! But those are so called digital formats, they should be further forced. ___ 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] Stop using _explicit atomic operations where not necessary.
Anton Khirnov:
> Memory ordering constraints other than the default (sequentially
> consistent) can behave in very unintuitive and unexpected ways, and so
> should be avoided unless there is a strong (typically performance)
> reason for using them. This holds especially for memory_order_relaxed,
> which imposes no ordering constraints.
I disagree with this: Adding ordering constraints is wrong, as it can
provide synchronization between different threads and this can mask
races. Providing synchronization as a byproduct should be avoided: Users
should know what they get. And if a user wants an allocation limit in
thread A to be in effect for allocations in thread B, then the user
should provide the synchronization him/herself.
Here is an example of a program that contains a data race that is masked
by this patch: If all allocations happen before av_max_alloc(3), then
tsan will complain about a data race; otherwise, it is silent, as the
write in av_max_alloc() synchronizes with the read in av_malloc(), so
that race = 1 is visible in the main thread later.
#include
#include
#include "libavutil/mem.h"
int race;
static void *second_thread(void *arg)
{
race = 1;
av_max_alloc(3);
return NULL;
}
int main()
{
pthread_t thread;
pthread_create(&thread, NULL, second_thread, NULL);
for (int i = 0; i < 150; i++)
av_malloc(i);
printf("%d\n", race);
pthread_join(thread, NULL);
}
- Andreas
> ---
> libavformat/fifo.c | 8
> libavutil/cpu.c| 8
> libavutil/mem.c| 10 +-
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> index 50656f78b7..2ac14207b8 100644
> --- a/libavformat/fifo.c
> +++ b/libavformat/fifo.c
> @@ -185,7 +185,7 @@ static int fifo_thread_write_packet(FifoThreadContext
> *ctx, AVPacket *pkt)
> int ret, s_idx;
>
> if (fifo->timeshift && pkt->dts != AV_NOPTS_VALUE)
> -atomic_fetch_sub_explicit(&fifo->queue_duration, next_duration(avf,
> pkt, &ctx->last_received_dts), memory_order_relaxed);
> +atomic_fetch_sub(&fifo->queue_duration, next_duration(avf, pkt,
> &ctx->last_received_dts));
>
> if (ctx->drop_until_keyframe) {
> if (pkt->flags & AV_PKT_FLAG_KEY) {
> @@ -454,7 +454,7 @@ static void *fifo_consumer_thread(void *data)
> av_log(avf, AV_LOG_INFO, "FIFO queue flushed\n");
>
> if (fifo->timeshift)
> -while (atomic_load_explicit(&fifo->queue_duration,
> memory_order_relaxed) < fifo->timeshift)
> +while (atomic_load(&fifo->queue_duration) < fifo->timeshift)
> av_usleep(1);
>
> ret = av_thread_message_queue_recv(queue, &msg, 0);
> @@ -594,7 +594,7 @@ static int fifo_write_packet(AVFormatContext *avf,
> AVPacket *pkt)
> }
>
> if (fifo->timeshift && pkt && pkt->dts != AV_NOPTS_VALUE)
> -atomic_fetch_add_explicit(&fifo->queue_duration, next_duration(avf,
> pkt, &fifo->last_sent_dts), memory_order_relaxed);
> +atomic_fetch_add(&fifo->queue_duration, next_duration(avf, pkt,
> &fifo->last_sent_dts));
>
> return ret;
> fail:
> @@ -621,7 +621,7 @@ static int fifo_write_trailer(AVFormatContext *avf)
> } else {
> now += delay;
> }
> -atomic_fetch_add_explicit(&fifo->queue_duration, delay,
> memory_order_relaxed);
> +atomic_fetch_add(&fifo->queue_duration, delay);
> elapsed += delay;
> if (elapsed > fifo->timeshift)
> break;
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index 8960415d00..8a6af81ae4 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
> @@ -89,15 +89,15 @@ void av_force_cpu_flags(int arg){
> arg |= AV_CPU_FLAG_MMX;
> }
>
> -atomic_store_explicit(&cpu_flags, arg, memory_order_relaxed);
> +atomic_store(&cpu_flags, arg);
> }
>
> int av_get_cpu_flags(void)
> {
> -int flags = atomic_load_explicit(&cpu_flags, memory_order_relaxed);
> +int flags = atomic_load(&cpu_flags);
> if (flags == -1) {
> flags = get_cpu_flags();
> -atomic_store_explicit(&cpu_flags, flags, memory_order_relaxed);
> +atomic_store(&cpu_flags, flags);
> }
> return flags;
> }
> @@ -221,7 +221,7 @@ int av_cpu_count(void)
> nb_cpus = sysinfo.dwNumberOfProcessors;
> #endif
>
> -if (!atomic_exchange_explicit(&printed, 1, memory_order_relaxed))
> +if (!atomic_exchange(&printed, 1))
> av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
>
> return nb_cpus;
> diff --git a/libavutil/mem.c b/libavutil/mem.c
> index a52d33d4a6..c216c0314f 100644
> --- a/libavutil/mem.c
> +++ b/libavutil/mem.c
> @@ -72,14 +72,14 @@ void free(void *ptr);
> static atomic_size_t max_alloc_size = ATOMIC_VAR_INIT(INT_MAX);
>
> void av_max_alloc(size_t max){
> -atomic_store_explicit(&max_alloc_size, max, memory_order_rela
Re: [FFmpeg-devel] [PATCH] fftools/cmdutils.c: Add cmd line option to override detection of cpu count
Hi,
Am 05.06.21 um 16:33 schrieb Anton Khirnov:
> Quoting Thilo Borgmann (2021-06-05 14:29:05)
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>> From 38612f3e1339354dbaa6be4f36072320ff71c707 Mon Sep 17 00:00:00 2001
>> From: Thilo Borgmann
>> Date: Sat, 5 Jun 2021 14:26:23 +0200
>> Subject: [PATCH] fftools/cmdutils.c: Add cmd line option to override
>> detection
>> of cpu count
>>
>> Suggested-By: ffm...@fb.com
>> ---
>> doc/fftools-common-opts.texi | 7 +++
>> fftools/cmdutils.c | 27 +++
>> fftools/cmdutils.h | 7 +++
>> libavutil/cpu.c | 14 ++
>> libavutil/cpu.h | 6 ++
>> 5 files changed, 61 insertions(+)
>>
>> [...]
>> /**
>> * Fallback for options that are not explicitly handled, these will be
>> * parsed through AVOptions.
>> @@ -239,6 +245,7 @@ void show_help_options(const OptionDef *options, const
>> char *msg, int req_flags,
>> { "report", 0,{ .func_arg = opt_report },
>> "generate a report" }, \
>> { "max_alloc", HAS_ARG, { .func_arg = opt_max_alloc },
>> "set maximum size of a single allocated block", "bytes" }, \
>> { "cpuflags",HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpuflags },
>> "force specific cpu flags", "flags" }, \
>> +{ "cpucount",HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpucount },
>> "force specific cpu count", "count" }, \
>> { "hide_banner", OPT_BOOL | OPT_EXPERT, {&hide_banner}, "do not
>> show program banner", "hide_banner" }, \
>> CMDUTILS_COMMON_OPTIONS_AVDEVICE
>> \
>>
>> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> index 52f6b9a3bf..ccd5b5adac 100644
>> --- a/libavutil/cpu.c
>> +++ b/libavutil/cpu.c
>> @@ -48,6 +48,7 @@
>> #endif
>>
>> static atomic_int cpu_flags = ATOMIC_VAR_INIT(-1);
>> +static atomic_int cpu_count = ATOMIC_VAR_INIT(-1);
>>
>> static int get_cpu_flags(void)
>> {
>> @@ -306,14 +307,27 @@ int av_cpu_count(void)
>> nb_cpus = sysinfo.dwNumberOfProcessors;
>> #endif
>>
>> +int count = atomic_load_explicit(&cpu_count, memory_order_relaxed);
>
> Just use a normal atomic_load().
>
>> [...]
>> +/**
>> + * Overrides cpu count detection and forces the specified count.
>> + * Count < 1 disables forcing of specific count.
>> + */
>> +void av_force_cpu_count(int count);
>
> I'd prefer if the name was namespaced as av_cpu_
For both of these, I copied the behavior of av_force_cpu_flags(). For function
names as well as the atomic load.
Let me know which way you prefer. If you prefer your reviewed version, I could
also send a patch for similar changes to av_force_cpu_flags() if that makes
sense.
All other remarks changed locally.
Thanks,
Thilo
___
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] Stop using _explicit atomic operations where not necessary.
James Almer:
> On 6/5/2021 11:27 AM, Anton Khirnov wrote:
>> Memory ordering constraints other than the default (sequentially
>> consistent) can behave in very unintuitive and unexpected ways, and so
>> should be avoided unless there is a strong (typically performance)
>> reason for using them. This holds especially for memory_order_relaxed,
>> which imposes no ordering constraints.
>
> Performance is important for FIFO, though. Could they use a laxer order
> at least for the fetch_sub and fetch_add cases?
>
> Also, commit fed50c4304e, which made cpu_flags an atomic type, states
> that ThreadSanitizer stopped reporting races on tests/cpu_init after
> that change, so maybe memory order is not important for it, only atomicity.
This is true: There can by definition be no data race involving an
atomic variable that is exclusively accessed via atomic operations: "The
execution of a program contains a data race if it contains two
conflicting actions in different threads, at least one of which is *not
atomic*, and neither happens before the other." (C11, 5.1.2.4.25)
Therefore fed50c4304eecb352e29ce789cdb96ea84d6162f and
a2a38b160620d91bc3f895dadc4501c589998b9c fixed data races (the latter
also a race condition); using sequentially consistent ordering meanwhile
brings no gain: It may provide synchronization between two threads
calling e.g. av_get_cpu_flags(), but the only effect of this is that
tsan might overlook buggy code that actually contains races. It notably
does not really establish an ordering: If two threads call
av_cpu_count() concurrently, then it is indetermined which of the two
threads will call av_log (if it has not already been called), but with
this patch it is certain that the second thread synchronizes with the
first thread and sees everything that the first thread has done so far
(which can mask bugs); and if we look at the test in
libavutil/tests/cpu_init.c, then all the possibilities that existed with
memory_order_relaxed also exist with memory_order_seq_cst:
- Thread 1 can read first, see that cpu_flags is uninitialized and
initialize it, followed by thread 2 seeing and reusing the already
initialized value.
- Thread 1 can read first, followed by thread 2 reading the value (with
both threads seeing that cpu_flags is uninitialized), followed by thread
1 storing its value, followed by thread 2 overwriting the value again;
the order of writes can also be the other way around.
- Same as the last one, but with the order of stores reversed.
- Exchanging the roles of thread 1 and thread 2 in the above scenarios
leads to the remaining cases.
> In any case these cpu and mem functions are hardly a bottleneck
> anywhere, and rarely called outside of debugging, so this change is ok.
>
Mem functions are rarely called outside of debugging?
>> ---
>> libavformat/fifo.c | 8
The threading in fifo.c is weird: A variable (overflow_flag) that is
guarded by a mutex is marked as volatile; moreover it appears that one
could avoid said mutex altogether by making overflow_flag atomic. And
finally, the worker thread is only destroyed in write_trailer, but if
this is never called, then it will never be destroyed. Furtermore, in
this case the worker thread might wait on a condition variable that is
destroyed in av_thread_message_queue_free(), which is undefined behaviour.
I don't know whether the accesses to queue_duration need a
memory_ordering different than memory_order_relaxed.
>> libavutil/cpu.c | 8
>> libavutil/mem.c | 10 +-
>> 3 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
>> index 50656f78b7..2ac14207b8 100644
>> --- a/libavformat/fifo.c
>> +++ b/libavformat/fifo.c
>> @@ -185,7 +185,7 @@ static int
>> fifo_thread_write_packet(FifoThreadContext *ctx, AVPacket *pkt)
>> int ret, s_idx;
>> if (fifo->timeshift && pkt->dts != AV_NOPTS_VALUE)
>> - atomic_fetch_sub_explicit(&fifo->queue_duration,
>> next_duration(avf, pkt, &ctx->last_received_dts), memory_order_relaxed);
>> + atomic_fetch_sub(&fifo->queue_duration, next_duration(avf,
>> pkt, &ctx->last_received_dts));
>> if (ctx->drop_until_keyframe) {
>> if (pkt->flags & AV_PKT_FLAG_KEY) {
>> @@ -454,7 +454,7 @@ static void *fifo_consumer_thread(void *data)
>> av_log(avf, AV_LOG_INFO, "FIFO queue flushed\n");
>> if (fifo->timeshift)
>> - while (atomic_load_explicit(&fifo->queue_duration,
>> memory_order_relaxed) < fifo->timeshift)
>> + while (atomic_load(&fifo->queue_duration) < fifo->timeshift)
>> av_usleep(1);
>> ret = av_thread_message_queue_recv(queue, &msg, 0);
>> @@ -594,7 +594,7 @@ static int fifo_write_packet(AVFormatContext *avf,
>> AVPacket *pkt)
>> }
>> if (fifo->timeshift && pkt && pkt->dts != AV_NOPTS_VALUE)
>> - atomic_fetch_add_explicit(&fifo->queue_duration,
>> next_duration(avf, pkt, &fifo
Re: [FFmpeg-devel] [PATCH] Stop using _explicit atomic operations where not necessary.
On 6/6/2021 8:39 AM, Andreas Rheinhardt wrote: James Almer: On 6/5/2021 11:27 AM, Anton Khirnov wrote: Memory ordering constraints other than the default (sequentially consistent) can behave in very unintuitive and unexpected ways, and so should be avoided unless there is a strong (typically performance) reason for using them. This holds especially for memory_order_relaxed, which imposes no ordering constraints. Performance is important for FIFO, though. Could they use a laxer order at least for the fetch_sub and fetch_add cases? Also, commit fed50c4304e, which made cpu_flags an atomic type, states that ThreadSanitizer stopped reporting races on tests/cpu_init after that change, so maybe memory order is not important for it, only atomicity. This is true: There can by definition be no data race involving an atomic variable that is exclusively accessed via atomic operations: "The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is *not atomic*, and neither happens before the other." (C11, 5.1.2.4.25) Therefore fed50c4304eecb352e29ce789cdb96ea84d6162f and a2a38b160620d91bc3f895dadc4501c589998b9c fixed data races (the latter also a race condition); using sequentially consistent ordering meanwhile brings no gain: It may provide synchronization between two threads calling e.g. av_get_cpu_flags(), but the only effect of this is that tsan might overlook buggy code that actually contains races. It notably does not really establish an ordering: If two threads call av_cpu_count() concurrently, then it is indetermined which of the two threads will call av_log (if it has not already been called), but with this patch it is certain that the second thread synchronizes with the first thread and sees everything that the first thread has done so far (which can mask bugs); and if we look at the test in libavutil/tests/cpu_init.c, then all the possibilities that existed with memory_order_relaxed also exist with memory_order_seq_cst: - Thread 1 can read first, see that cpu_flags is uninitialized and initialize it, followed by thread 2 seeing and reusing the already initialized value. - Thread 1 can read first, followed by thread 2 reading the value (with both threads seeing that cpu_flags is uninitialized), followed by thread 1 storing its value, followed by thread 2 overwriting the value again; the order of writes can also be the other way around. - Same as the last one, but with the order of stores reversed. - Exchanging the roles of thread 1 and thread 2 in the above scenarios leads to the remaining cases. In any case these cpu and mem functions are hardly a bottleneck anywhere, and rarely called outside of debugging, so this change is ok. Mem functions are rarely called outside of debugging? I was specifically thinking about about av_max_alloc(), but overlooked the fact max_alloc_size is read by av_malloc() an co, which are obviously not for debug only. Sorry. ___ 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] fftools/cmdutils.c: Add cmd line option to override detection of cpu count
Thilo Borgmann:
> Hi,
>
> add an option to override auto-detection of cpu count. Defaults to
> auto-detection, of course.
>
> -Thilo
>
>
> doc/fftools-common-opts.texi | 7 +++
> fftools/cmdutils.c | 27 +++
> fftools/cmdutils.h | 7 +++
> libavutil/cpu.c | 14 ++
> libavutil/cpu.h | 6 ++
The changes to libavutil and cmdutils should be in separate patches; and
of course the commit message should mention that you are changing
libavutil -- I would have nearly missed this patch (given that I don't
pay much attention to fftools in general).
>
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index 52f6b9a3bf..ccd5b5adac 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
52f6b9a3bf is the state of cpu.c after
e387fcd01cb84d9493f3b96158addd2a85f086c6. This is completely outdated.
>
> @@ -306,14 +307,27 @@ int av_cpu_count(void)
> nb_cpus = sysinfo.dwNumberOfProcessors;
> #endif
>
> +int count = atomic_load_explicit(&cpu_count, memory_order_relaxed);
> +
> if (!printed) {
> av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
> +if (count > 0) {
> +av_log(NULL, AV_LOG_DEBUG, "overriding to %d logical cores\n",
> count);
> +}
> printed = 1;
> }
>
> +if (count > 0) {
> +nb_cpus = count;
> +}
> +
> return nb_cpus;
> }
>
In particular, this hunk doesn't apply to git master at all any more
(did I already mention that cpu.c only has 245 lines atm, not >300?).
And the declaration of count would lead to a statement-after-declaration
warning.
- Andreas
___
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] Stop using _explicit atomic operations where not necessary.
Quoting Andreas Rheinhardt (2021-06-06 11:13:00) > Anton Khirnov: > > Memory ordering constraints other than the default (sequentially > > consistent) can behave in very unintuitive and unexpected ways, and so > > should be avoided unless there is a strong (typically performance) > > reason for using them. This holds especially for memory_order_relaxed, > > which imposes no ordering constraints. > > I disagree with this: Adding ordering constraints is wrong, as it can > provide synchronization between different threads and this can mask > races. Providing synchronization as a byproduct should be avoided: Users > should know what they get. And if a user wants an allocation limit in > thread A to be in effect for allocations in thread B, then the user > should provide the synchronization him/herself. I do not agree. C11 default is sequential consistency, therefore our public API should provide sequential consistency. My other concern is that people are cargo culting this code around without understanding what it really does. Again, sequentially consistent atomics make that safer, since they do what you'd expect them to. > > Here is an example of a program that contains a data race that is masked > by this patch: If all allocations happen before av_max_alloc(3), then > tsan will complain about a data race; otherwise, it is silent, as the > write in av_max_alloc() synchronizes with the read in av_malloc(), so > that race = 1 is visible in the main thread later. This example is highly artificial and IMO not relevant, since - nothing in the libraries should call av_max_malloc() or other functions that modify global state - it is not our job to look for races in user programs -- 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".
[FFmpeg-devel] [PATCH] fate: fix input arguments for fate-unknown_layout-ac3
The input stream is a raw 16 bit audio one, so trying to read it as a 32 bit one is incorrect. The test can and will autoinsert a resampler as needed. Use the oneline comparison for the final result as well, while at it. Signed-off-by: James Almer --- tests/fate/ffmpeg.mak | 4 +++- tests/ref/fate/unknown_layout-ac3 | 1 - 2 files changed, 3 insertions(+), 2 deletions(-) delete mode 100644 tests/ref/fate/unknown_layout-ac3 diff --git a/tests/fate/ffmpeg.mak b/tests/fate/ffmpeg.mak index 4dfb77d250..42152aca64 100644 --- a/tests/fate/ffmpeg.mak +++ b/tests/fate/ffmpeg.mak @@ -82,8 +82,10 @@ fate-unknown_layout-pcm: CMD = md5 \ FATE_FFMPEG-$(call ALLYES, PCM_S16LE_DEMUXER AC3_MUXER PCM_S16LE_DECODER AC3_FIXED_ENCODER) += fate-unknown_layout-ac3 fate-unknown_layout-ac3: $(AREF) +fate-unknown_layout-ac3: CMP = oneline +fate-unknown_layout-ac3: REF = 9455adf10ae2a09850c57f2993fb4316 fate-unknown_layout-ac3: CMD = md5 -auto_conversion_filters \ - -guess_layout_max 0 -f s32le -ac 1 -ar 44100 -i $(TARGET_PATH)/$(AREF) \ + -guess_layout_max 0 -f s16le -ac 1 -ar 44100 -i $(TARGET_PATH)/$(AREF) \ -f ac3 -flags +bitexact -c ac3_fixed diff --git a/tests/ref/fate/unknown_layout-ac3 b/tests/ref/fate/unknown_layout-ac3 deleted file mode 100644 index 719a44aacf..00 --- a/tests/ref/fate/unknown_layout-ac3 +++ /dev/null @@ -1 +0,0 @@ -febdb165cfd6cba375aa086195e61213 -- 2.31.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] fftools/cmdutils.c: Add cmd line option to override detection of cpu count
Am 06.06.21 um 14:35 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>
>>
>> doc/fftools-common-opts.texi | 7 +++
>> fftools/cmdutils.c | 27 +++
>> fftools/cmdutils.h | 7 +++
>> libavutil/cpu.c | 14 ++
>> libavutil/cpu.h | 6 ++
>
> The changes to libavutil and cmdutils should be in separate patches; and
> of course the commit message should mention that you are changing
> libavutil -- I would have nearly missed this patch (given that I don't
> pay much attention to fftools in general).
>
>>
>> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> index 52f6b9a3bf..ccd5b5adac 100644
>> --- a/libavutil/cpu.c
>> +++ b/libavutil/cpu.c
>
> 52f6b9a3bf is the state of cpu.c after
> e387fcd01cb84d9493f3b96158addd2a85f086c6. This is completely outdated.
Yes, messed up branches for the patch, thx!
>>
>> @@ -306,14 +307,27 @@ int av_cpu_count(void)
>> nb_cpus = sysinfo.dwNumberOfProcessors;
>> #endif
>>
>> +int count = atomic_load_explicit(&cpu_count, memory_order_relaxed);
>> +
>> if (!printed) {
>> av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
>> +if (count > 0) {
>> +av_log(NULL, AV_LOG_DEBUG, "overriding to %d logical cores\n",
>> count);
>> +}
>> printed = 1;
>> }
>>
>> +if (count > 0) {
>> +nb_cpus = count;
>> +}
>> +
>> return nb_cpus;
>> }
>>
> In particular, this hunk doesn't apply to git master at all any more
> (did I already mention that cpu.c only has 245 lines atm, not >300?).
> And the declaration of count would lead to a statement-after-declaration
> warning.
Done locally to apply to today's HEAD. I think I'll wait with sending both
patches once we decided on atomic loads in "[PATCH] Stop using _explicit atomic
operations where not necessary.".
Thanks,
Thilo
___
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] fftools/cmdutils.c: Add cmd line option to override detection of cpu count
Am 06.06.21 um 14:35 schrieb Andreas Rheinhardt:
> Thilo Borgmann:
>> Hi,
>>
>> add an option to override auto-detection of cpu count. Defaults to
>> auto-detection, of course.
>>
>> -Thilo
>>
>
>>
>> doc/fftools-common-opts.texi | 7 +++
>> fftools/cmdutils.c | 27 +++
>> fftools/cmdutils.h | 7 +++
>> libavutil/cpu.c | 14 ++
>> libavutil/cpu.h | 6 ++
>
> The changes to libavutil and cmdutils should be in separate patches; and
> of course the commit message should mention that you are changing
> libavutil -- I would have nearly missed this patch (given that I don't
> pay much attention to fftools in general).
>
>>
>> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
>> index 52f6b9a3bf..ccd5b5adac 100644
>> --- a/libavutil/cpu.c
>> +++ b/libavutil/cpu.c
>
> 52f6b9a3bf is the state of cpu.c after
> e387fcd01cb84d9493f3b96158addd2a85f086c6. This is completely outdated.
Yes, messed up branches for the patch, thx!
>>
>> @@ -306,14 +307,27 @@ int av_cpu_count(void)
>> nb_cpus = sysinfo.dwNumberOfProcessors;
>> #endif
>>
>> +int count = atomic_load_explicit(&cpu_count, memory_order_relaxed);
>> +
>> if (!printed) {
>> av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n", nb_cpus);
>> +if (count > 0) {
>> +av_log(NULL, AV_LOG_DEBUG, "overriding to %d logical cores\n",
>> count);
>> +}
>> printed = 1;
>> }
>>
>> +if (count > 0) {
>> +nb_cpus = count;
>> +}
>> +
>> return nb_cpus;
>> }
>>
> In particular, this hunk doesn't apply to git master at all any more
> (did I already mention that cpu.c only has 245 lines atm, not >300?).
> And the declaration of count would lead to a statement-after-declaration
> warning.
Done locally to apply to today's HEAD. I think I'll wait with sending both
patches once we decided on atomic loads in "[PATCH] Stop using _explicit atomic
operations where not necessary.".
Thanks,
Thilo
___
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 5/5] avfilter/af_drmeter: Check that there is data
Fixes: floating point division by 0
Fixes: -nan is outside the range of representable values of type 'int'
Fixes: Ticket8307
Signed-off-by: Michael Niedermayer
---
libavfilter/af_drmeter.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavfilter/af_drmeter.c b/libavfilter/af_drmeter.c
index 3774259da3..58932fe6c5 100644
--- a/libavfilter/af_drmeter.c
+++ b/libavfilter/af_drmeter.c
@@ -167,6 +167,11 @@ static void print_stats(AVFilterContext *ctx)
float chdr, secondpeak, rmssum = 0;
int i, j, first = 0;
+if (!p->nb_samples) {
+av_log(ctx, AV_LOG_INFO, "No data, dynamic range not
meassurable\n");
+return;
+}
+
finish_block(p);
for (i = 0; i <= 1; i++) {
--
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/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
Fixes: floating point division by 0
Fixes: undefined behavior in handling NaN
Fixes: Ticket 8268
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_ciescope.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_ciescope.c b/libavfilter/vf_ciescope.c
index b3b906f517..f8fe554c06 100644
--- a/libavfilter/vf_ciescope.c
+++ b/libavfilter/vf_ciescope.c
@@ -844,6 +844,9 @@ rgb_to_xy(double rc,
{
double sum;
+if (rc == 0 && gc == 0 && bc == 0)
+rc = gc = bc = 0.1/65536;
+
*x = m[0][0] * rc + m[0][1] * gc + m[0][2] * bc;
*y = m[1][0] * rc + m[1][1] * gc + m[1][2] * bc;
*z = m[2][0] * rc + m[2][1] * gc + m[2][2] * bc;
--
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 1/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
I am sorry, what??? ___ 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/5] avfilter/vf_mestimate: Check b_count
Fixes: left shift of negative value -1
Fixes: Ticket8270
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_mestimate.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_mestimate.c b/libavfilter/vf_mestimate.c
index daf7fde95f..f1935244c1 100644
--- a/libavfilter/vf_mestimate.c
+++ b/libavfilter/vf_mestimate.c
@@ -100,6 +100,9 @@ static int config_input(AVFilterLink *inlink)
s->b_height = inlink->h >> s->log2_mb_size;
s->b_count = s->b_width * s->b_height;
+if (s->b_count == 0)
+return AVERROR(EINVAL);
+
for (i = 0; i < 3; i++) {
s->mv_table[i] = av_mallocz_array(s->b_count, sizeof(*s->mv_table[0]));
if (!s->mv_table[i])
--
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 4/5] avfilter/vf_fftdnoiz: Use lrintf() in export_row8()
Fixes: 1.04064e+10 is outside the range of representable values of type 'int' Fixes: Ticket 8279 Signed-off-by: Michael Niedermayer --- libavfilter/vf_fftdnoiz.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vf_fftdnoiz.c b/libavfilter/vf_fftdnoiz.c index 7f4a6d88cf..8dc50b776f 100644 --- a/libavfilter/vf_fftdnoiz.c +++ b/libavfilter/vf_fftdnoiz.c @@ -161,7 +161,7 @@ static void export_row8(FFTComplex *src, uint8_t *dst, int rw, float scale, int int j; for (j = 0; j < rw; j++) -dst[j] = av_clip_uint8(src[j].re * scale + 0.5f); +dst[j] = av_clip_uint8(lrintf(src[j].re * scale)); } static void import_row16(FFTComplex *dst, uint8_t *srcp, int rw) -- 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/5] avfilter/vf_dctdnoiz: Check threads
Fixes: floating point division by 0
Fixes: Ticket 8269
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_dctdnoiz.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c
index 63b1b29ea2..f09ab19c4d 100644
--- a/libavfilter/vf_dctdnoiz.c
+++ b/libavfilter/vf_dctdnoiz.c
@@ -568,6 +568,9 @@ static int config_input(AVFilterLink *inlink)
av_log(ctx, AV_LOG_DEBUG, "threads: [max=%d hmax=%d user=%d] => %d\n",
MAX_THREADS, max_slice_h, ff_filter_get_nb_threads(ctx),
s->nb_threads);
+if (!s->nb_threads)
+return AVERROR(EINVAL);
+
s->p_linesize = linesize = FFALIGN(s->pr_width, 32);
for (i = 0; i < 2; i++) {
s->cbuf[i][0] = av_malloc_array(linesize * s->pr_height,
sizeof(*s->cbuf[i][0]));
--
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] fftools/cmdutils.c: Add cmd line option to override detection of cpu count
Quoting Thilo Borgmann (2021-06-06 12:44:41)
> Hi,
>
> Am 05.06.21 um 16:33 schrieb Anton Khirnov:
> > Quoting Thilo Borgmann (2021-06-05 14:29:05)
> >> Hi,
> >>
> >> add an option to override auto-detection of cpu count. Defaults to
> >> auto-detection, of course.
> >>
> >> -Thilo
> >>
> >> From 38612f3e1339354dbaa6be4f36072320ff71c707 Mon Sep 17 00:00:00 2001
> >> From: Thilo Borgmann
> >> Date: Sat, 5 Jun 2021 14:26:23 +0200
> >> Subject: [PATCH] fftools/cmdutils.c: Add cmd line option to override
> >> detection
> >> of cpu count
> >>
> >> Suggested-By: ffm...@fb.com
> >> ---
> >> doc/fftools-common-opts.texi | 7 +++
> >> fftools/cmdutils.c | 27 +++
> >> fftools/cmdutils.h | 7 +++
> >> libavutil/cpu.c | 14 ++
> >> libavutil/cpu.h | 6 ++
> >> 5 files changed, 61 insertions(+)
> >>
> >> [...]
>
> >> /**
> >> * Fallback for options that are not explicitly handled, these will be
> >> * parsed through AVOptions.
> >> @@ -239,6 +245,7 @@ void show_help_options(const OptionDef *options, const
> >> char *msg, int req_flags,
> >> { "report", 0,{ .func_arg = opt_report },
> >>"generate a report" }, \
> >> { "max_alloc", HAS_ARG, { .func_arg = opt_max_alloc },
> >>"set maximum size of a single allocated block", "bytes" }, \
> >> { "cpuflags",HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpuflags },
> >>"force specific cpu flags", "flags" }, \
> >> +{ "cpucount",HAS_ARG | OPT_EXPERT, { .func_arg = opt_cpucount },
> >>"force specific cpu count", "count" }, \
> >> { "hide_banner", OPT_BOOL | OPT_EXPERT, {&hide_banner}, "do not
> >> show program banner", "hide_banner" }, \
> >> CMDUTILS_COMMON_OPTIONS_AVDEVICE
> >> \
> >>
> >> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> >> index 52f6b9a3bf..ccd5b5adac 100644
> >> --- a/libavutil/cpu.c
> >> +++ b/libavutil/cpu.c
> >> @@ -48,6 +48,7 @@
> >> #endif
> >>
> >> static atomic_int cpu_flags = ATOMIC_VAR_INIT(-1);
> >> +static atomic_int cpu_count = ATOMIC_VAR_INIT(-1);
> >>
> >> static int get_cpu_flags(void)
> >> {
> >> @@ -306,14 +307,27 @@ int av_cpu_count(void)
> >> nb_cpus = sysinfo.dwNumberOfProcessors;
> >> #endif
> >>
> >> +int count = atomic_load_explicit(&cpu_count, memory_order_relaxed);
> >
> > Just use a normal atomic_load().
> >
> >> [...]
>
> >> +/**
> >> + * Overrides cpu count detection and forces the specified count.
> >> + * Count < 1 disables forcing of specific count.
> >> + */
> >> +void av_force_cpu_count(int count);
> >
> > I'd prefer if the name was namespaced as av_cpu_
>
> For both of these, I copied the behavior of av_force_cpu_flags(). For
> function names as well as the atomic load.
> Let me know which way you prefer. If you prefer your reviewed version, I
> could also send a patch for similar changes to av_force_cpu_flags() if that
> makes sense.
Sadly we cannot change existing function names. But at least new
functions can use consistent namespacing.
--
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] avcodec/libopenjpeg: Interpret cinema profiles as XYZ
On Sun, Jun 06, 2021 at 09:27:32AM +0300, Valerii Zapodovnikov wrote:
> From: Rémi Achard
>
> Patch should be applied to decode XYZ samples with not native
> decoder in ffmpeg (-c:v libopenjpeg, not -c:v jpeg2000). jpeg2000
> works already.
> Now, this is AFAIK a patch that should be applied after upstream's
> patch: https://github.com/uclouvain/openjpeg/pull/1200
> Please note that jpeg2000 XYZ is not bitperfect compared to openjpeg
> see #4829#comment:3. Some pixels will be different, like in sYCC. I
> consider both bugs. Also pixel_format can be forced by
> "-pixel_format xyz12le".
> ---
> libavcodec/libopenjpegdec.c | 44 +++--
> 1 file changed, 27 insertions(+), 17 deletions(-)
This breaks build
libavcodec/libopenjpegdec.c: In function ‘libopenjpeg_guess_pix_fmt’:
libavcodec/libopenjpegdec.c:203:14: error: ‘opj_image_t {aka const struct
opj_image}’ has no member named ‘rsiz’
if (image->rsiz == FF_PROFILE_JPEG2000_DCINEMA_2K ||
^~
libavcodec/libopenjpegdec.c:204:14: error: ‘opj_image_t {aka const struct
opj_image}’ has no member named ‘rsiz’
image->rsiz == FF_PROFILE_JPEG2000_DCINEMA_4K) {
^~
ffbuild/common.mak:67: recipe for target 'libavcodec/libopenjpegdec.o' failed
make: *** [libavcodec/libopenjpegdec.o] Error 1
changes to configure, version / feature checks are missing
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."
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] avcodec/libopenjpeg: Interpret cinema profiles as XYZ
Did you even read the commit message? You need to apply a patch to openjpeg itself. Sigh. ___ 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/5] avfilter/vf_dctdnoiz: Check threads
Quoting Michael Niedermayer (2021-06-06 15:47:54) > Fixes: floating point division by 0 > Fixes: Ticket 8269 > > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_dctdnoiz.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c > index 63b1b29ea2..f09ab19c4d 100644 > --- a/libavfilter/vf_dctdnoiz.c > +++ b/libavfilter/vf_dctdnoiz.c > @@ -568,6 +568,9 @@ static int config_input(AVFilterLink *inlink) > av_log(ctx, AV_LOG_DEBUG, "threads: [max=%d hmax=%d user=%d] => %d\n", > MAX_THREADS, max_slice_h, ff_filter_get_nb_threads(ctx), > s->nb_threads); > > +if (!s->nb_threads) > +return AVERROR(EINVAL); > + I presume the crash happens due to max_slice_h evaluating to 0. Wouldn't it then make more sense to check max_slice_h directly? Or perhaps clip it from below rather than failing? -- 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] avcodec/libopenjpeg: Interpret cinema profiles as XYZ
On Sun, Jun 06, 2021 at 05:42:54PM +0300, Valerii Zapodovnikov wrote: > Did you even read the commit message? You need to apply a patch to openjpeg > itself. Sigh. yes i read your commit message. you are changing the API/ABI of openjpeg and doing a matching change in the interface in ffmpeg to openjpeg. breaking support for the previous version with no check (not ok) breaking support for all existing distributions (not ok) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf 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 v2 14/22] lavfi/vpp_qsv: double the framerate for deinterlacing
Hi Haihao,
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> ---
> libavfilter/vf_vpp_qsv.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index 29ba220665..ec35f85b04 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -255,10 +255,14 @@ static int config_input(AVFilterLink *inlink)
> int ret;
> int64_t ow, oh;
>
> -if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> +/* Ignore user's setting for framerate when deinterlacing is used */
> +if (vpp->deinterlace)
> +vpp->framerate = av_mul_q(inlink->frame_rate,
> + (AVRational){ 2, 1 });
> +else if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> vpp->framerate = inlink->frame_rate;
No objection, just considering would it be better to prompt a warning
for users instead of just ignoring the user 's setting?
- linjie
___
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] avcodec/libopenjpeg: Interpret cinema profiles as XYZ
Actually it is not my patch (as should be obvious as From: is not me) and *NO* changes in API/ABI of openjpeg are happening with upsream patch. As for your ABI... There is only one correct way to manipulate openjpeg API, if you did that wrong, it is your problem. Standard thing: "unexpected that user code would allocate it with sizeof(opj_image_t)." I am just notifying your on this. Upstream is still not ready even, LOL. ___ 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 13/22] lavfi/scale_qsv: add more input / output pixel formats
On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
>
> NV12 and P010 are added
>
> $ ffmpeg -init_hw_device qsv -c:v h264_qsv -i input.h264 -vf
> "scale_qsv=format=p010" -f null -
> ---
> libavfilter/vf_vpp_qsv.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index bceee8c4df..29ba220665 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -665,7 +665,10 @@ DEFINE_QSV_FILTER(vpp, vpp, "VPP");
> static int qsvscale_query_formats(AVFilterContext *ctx)
> {
> static const enum AVPixelFormat pixel_formats[] = {
> -AV_PIX_FMT_QSV, AV_PIX_FMT_NONE,
> +AV_PIX_FMT_NV12,
> +AV_PIX_FMT_P010,
> +AV_PIX_FMT_QSV,
> +AV_PIX_FMT_NONE,
> };
> AVFilterFormats *pix_fmts = ff_make_format_list(pixel_formats);
>
LGTM, also verified it works as expected, thx.
- Linjie
___
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 13/22] lavfi/scale_qsv: add more input / output pixel formats
I hope it is the case since there was a problem with Intel P010 in Intel. #8055, comment 1, sample_YUV_intel10bits(P010LE).7z I still do not know what pixel format to force to decode that sample :) ___ 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/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote: > I am sorry, what??? If that is intended as a review comment, please compose a english sentance which represents what you are trying to convey. That way others know what you mean. The goal of review is to improve code Anyway to elaborate on the rather trivial change the code before the change has undefined behavior, that is a bug in C per definition of what a bug is pretty much. the change tried to replace the used value with one thats close and not undefined. we could skip black pixels or also use x=y=0 but later is discontinous on all pathes with non negative color leading to black so it felt a bit strange. But probably x=y=0 is a more strictly correct choice, so ill change it to that. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf 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] ffmpeg: add -fpsmin to clamp output framerate
So did you fix your gmail account? Also, what happened to FATE? Broken? BTW, I just logged in my nvidia account through apple id and that email was marked as spam too, but because of my filter it was not send into spam! 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".
Re: [FFmpeg-devel] [PATCH 1/5] avfilter/vf_ciescope: Handle black as very dark neutral gray
вс, 6 июн. 2021 г., 18:35 Michael Niedermayer : > On Sun, Jun 06, 2021 at 04:50:41PM +0300, Valerii Zapodovnikov wrote: > > I am sorry, what??? > > If that is intended as a review comment, please compose > a english sentance which represents what you are trying to convey. > That way others know what you mean. > > The goal of review is to improve code > > Anyway to elaborate on the rather trivial change > the code before the change has undefined behavior, that is a bug > in C per definition of what a bug is pretty much. > the change tried to replace the used value with one thats close > and not undefined. > we could skip black pixels or also use x=y=0 but later is > discontinous on all pathes with non negative color leading to black > so it felt a bit strange. But probably x=y=0 is a more strictly correct > choice, so ill change it to that. > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Many that live deserve death. And some that die deserve life. Can you give > it to them? Then do not be too eager to deal out death in judgement. For > even the very wise cannot see all ends. -- Gandalf > ___ > 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". > Nice, please change to that. And actually first link in google says https://stackoverflow.com/questions/42926763/ that it was defined in Annex F of ISO/IEC 9899 and gcc can do it, while clang cannot. I am not sure how one catches such NAN exceptions though. Moreover clang also wants that https://bugs.llvm.org/show_bug.cgi?id=19535#c13 and https://bugs.llvm.org/show_bug.cgi?id=17005, the last one even says and I quote: "The most visible issue caused by this is apparently that using -fsanitize=undefined on programs that make use of floating point division by 0.0 (which is perfectly legal udner IEEE floats) will print "runtime error: division by zero". (Also see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720935) It's also scary to think that your program might run slightly incorrectly in corner cases under clang, while it's correct under gcc (at least with -std=c99, gcc intentionally breaks floating point semantics with -std=gnu99)." Another bug in compiler, nothing to worry about IMHO. > ___ 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 14/22] lavfi/vpp_qsv: double the framerate for deinterlacing
On Sun, 2021-06-06 at 22:56 +0800, Linjie Fu wrote:
> Hi Haihao,
>
> On Mon, May 17, 2021 at 11:30 AM Haihao Xiang wrote:
> >
> > ---
> > libavfilter/vf_vpp_qsv.c | 8 ++--
> > 1 file changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > index 29ba220665..ec35f85b04 100644
> > --- a/libavfilter/vf_vpp_qsv.c
> > +++ b/libavfilter/vf_vpp_qsv.c
> > @@ -255,10 +255,14 @@ static int config_input(AVFilterLink *inlink)
> > int ret;
> > int64_t ow, oh;
> >
> > -if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> > +/* Ignore user's setting for framerate when deinterlacing is used */
> > +if (vpp->deinterlace)
> > +vpp->framerate = av_mul_q(inlink->frame_rate,
> > + (AVRational){ 2, 1 });
> > +else if (vpp->framerate.den == 0 || vpp->framerate.num == 0)
> > vpp->framerate = inlink->frame_rate;
>
> No objection, just considering would it be better to prompt a warning
> for users instead of just ignoring the user 's setting?
Thanks for the comment, I will update it.
>
> - linjie
___
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 13/22] lavfi/scale_qsv: add more input / output pixel formats
> I hope it is the case since there was a problem with Intel P010 in Intel. > > #8055, comment 1, sample_YUV_intel10bits(P010LE).7z The MSB 10bit is available for P010 in FFmpeg, however it is the LSB 10bit in your file. > > I still do not know what pixel format to force to decode that sample :) AFAIK FFmpeg didn't define a pixel format for your sample. Thanks Haihao > ___ > 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 v2 13/22] lavfi/scale_qsv: add more input / output pixel formats
So there are 4 formats two for le and 2 for be? Oogh. Do you know which one is used for dshow? ___ 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] Stop using _explicit atomic operations where not necessary.
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-06-06 11:13:00)
>> Anton Khirnov:
>>> Memory ordering constraints other than the default (sequentially
>>> consistent) can behave in very unintuitive and unexpected ways, and so
>>> should be avoided unless there is a strong (typically performance)
>>> reason for using them. This holds especially for memory_order_relaxed,
>>> which imposes no ordering constraints.
>>
>> I disagree with this: Adding ordering constraints is wrong, as it can
>> provide synchronization between different threads and this can mask
>> races. Providing synchronization as a byproduct should be avoided: Users
>> should know what they get. And if a user wants an allocation limit in
>> thread A to be in effect for allocations in thread B, then the user
>> should provide the synchronization him/herself.
>
> I do not agree. C11 default is sequential consistency, therefore our
> public API should provide sequential consistency.
>
1. The atomics here are not part of the public API at all: The
documentation of none of the functions involved mentions atomics or
synchronization etc. at all (which means that if a user wants
synchronization between threads, he should take care of it himself). We
could change the implementation to not use atomics at all (e.g. by
wrapping everything in mutexes, which needn't be sequentially consistent).
(Furthermore, in case of libavformat/fifo.c this does not even come
close to affecting the public API, given that we are talking about
synchronization between the user thread and a thread owned by us; in
case of av_cpu_count() the atomics only exist because of an av_log(),
there is no reason for a user to believe that synchronization is even
involved.)
2. I don't buy the argument:
Which memory ordering to use should be decided based upon what one wants
and needs; one should not blindly use one because it is the default or
recommended by some authority (doing so smells like cargo cult). In case
of av_get_cpu_flags()+av_force_cpu_flags(), all one wants is that one
can just load and write the value; given that there is no restriction
loads a valid value (i.e. no torn reads/writes) and one wants that one
can access this function by multiple threads simultaneously without
races. Atomics provide this even with memory_order_relaxed. In case of
av_cpu_count() all that is desired is that av_log() is only called once;
an atomic_exchange provides this automatically, even with
memory_order_relaxed. The av_max_alloc()+av_malloc/... combination is
just like av_get/force_cpu_flags().
> My other concern is that people are cargo culting this code around
> without understanding what it really does. Again, sequentially
> consistent atomics make that safer, since they do what you'd expect them
> to.
>
Are you really advocating that we write our code in such a way that
makes it safe for cargo-culters to copy it?
>>
>> Here is an example of a program that contains a data race that is masked
>> by this patch: If all allocations happen before av_max_alloc(3), then
>> tsan will complain about a data race; otherwise, it is silent, as the
>> write in av_max_alloc() synchronizes with the read in av_malloc(), so
>> that race = 1 is visible in the main thread later.
>
> This example is highly artificial and IMO not relevant, since
> - nothing in the libraries should call av_max_malloc() or other
> functions that modify global state
Here is an example with a function that we actually use:
#include
#include
#include "libavutil/cpu.h"
#include "libavutil/mem.h"
int race;
static void *second_thread(void *arg)
{
race = 1;
printf("Second thread CPU count %d\n", av_cpu_count());
return NULL;
}
int main()
{
pthread_t thread;
pthread_create(&thread, NULL, second_thread, NULL);
/* Do some work/waste some time */
for (int i = 0; i < 150; i++)
av_malloc(i);
int count = av_cpu_count();
printf("%d, count %d\n", race, count);
pthread_join(thread, NULL);
}
(The difference between memory_order_seq_cst and using pairs of
memory_order_release-memory_order_acquire (or memory_order_acq_rel) is
that there is a single (i.e. global) total order for all
memory_order_seq_cst operations; so using these is a bit like a
modification of global state.)
> - it is not our job to look for races in user programs
>
True, but making it more difficult for users to find races is not nice.
- Andreas
___
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/5] avfilter/vf_dctdnoiz: Check threads
On Sun, Jun 06, 2021 at 04:52:13PM +0200, Anton Khirnov wrote: > Quoting Michael Niedermayer (2021-06-06 15:47:54) > > Fixes: floating point division by 0 > > Fixes: Ticket 8269 > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/vf_dctdnoiz.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavfilter/vf_dctdnoiz.c b/libavfilter/vf_dctdnoiz.c > > index 63b1b29ea2..f09ab19c4d 100644 > > --- a/libavfilter/vf_dctdnoiz.c > > +++ b/libavfilter/vf_dctdnoiz.c > > @@ -568,6 +568,9 @@ static int config_input(AVFilterLink *inlink) > > av_log(ctx, AV_LOG_DEBUG, "threads: [max=%d hmax=%d user=%d] => %d\n", > > MAX_THREADS, max_slice_h, ff_filter_get_nb_threads(ctx), > > s->nb_threads); > > > > +if (!s->nb_threads) > > +return AVERROR(EINVAL); > > + > > I presume the crash happens due to max_slice_h evaluating to 0. Wouldn't > it then make more sense to check max_slice_h directly? ok will change it to that > Or perhaps clip > it from below rather than failing? the video was 1x1 pixel, maybe i lack imagination but i see no usecase for applying dctdnoiz to a 1x1 video thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable 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] avcodec/elbg: Increase some fields to 64bit
Fixes: Ticket8312
Fixes: Ticket8321
Signed-off-by: Michael Niedermayer
---
libavcodec/elbg.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/elbg.c b/libavcodec/elbg.c
index b6049c938b..63659dda8b 100644
--- a/libavcodec/elbg.c
+++ b/libavcodec/elbg.c
@@ -45,12 +45,12 @@ typedef struct cell_s {
* ELBG internal data
*/
typedef struct elbg_data {
-int error;
+int64_t error;
int dim;
int numCB;
int *codebook;
cell **cells;
-int *utility;
+int64_t *utility;
int64_t *utility_inc;
int *nearest_cb;
int *points;
@@ -265,7 +265,8 @@ static void update_utility_and_n_cb(elbg_data *elbg, int
idx, int newutility)
*/
static void try_shift_candidate(elbg_data *elbg, int idx[3])
{
-int j, k, olderror=0, newerror, cont=0;
+int j, k, cont=0;
+int64_t olderror=0, newerror;
int newutility[3];
int *newcentroid[3] = {
elbg->scratchbuf,
@@ -375,19 +376,20 @@ int avpriv_do_elbg(int *points, int dim, int numpoints,
int *codebook,
int dist;
elbg_data elbg_d;
elbg_data *elbg = &elbg_d;
-int i, j, k, last_error, steps = 0, ret = 0;
+int i, j, k, steps = 0, ret = 0;
int *dist_cb = av_malloc_array(numpoints, sizeof(int));
int *size_part = av_malloc_array(numCB, sizeof(int));
cell *list_buffer = av_malloc_array(numpoints, sizeof(cell));
cell *free_cells;
int best_dist, best_idx = 0;
+int64_t last_error;
-elbg->error = INT_MAX;
+elbg->error = INT64_MAX;
elbg->dim = dim;
elbg->numCB = numCB;
elbg->codebook = codebook;
elbg->cells = av_malloc_array(numCB, sizeof(cell *));
-elbg->utility = av_malloc_array(numCB, sizeof(int));
+elbg->utility = av_malloc_array(numCB, sizeof(*elbg->utility));
elbg->nearest_cb = closest_cb;
elbg->points = points;
elbg->utility_inc = av_malloc_array(numCB, sizeof(*elbg->utility_inc));
@@ -405,7 +407,7 @@ int avpriv_do_elbg(int *points, int dim, int numpoints, int
*codebook,
free_cells = list_buffer;
last_error = elbg->error;
steps++;
-memset(elbg->utility, 0, numCB*sizeof(int));
+memset(elbg->utility, 0, numCB*sizeof(*elbg->utility));
memset(elbg->cells, 0, numCB*sizeof(cell *));
elbg->error = 0;
--
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 v2 13/22] lavfi/scale_qsv: add more input / output pixel formats
> So there are 4 formats two for le and 2 for be? Yes, I think so. > Oogh. Do you know which one > is used for dshow? I didn't use dshow, but I think it should be the format using MSB 10bit, see https://docs.microsoft.com/en-us/windows/win32/medfound/10-bit-and-16-bit-yuv-video-formats#overview > ___ > 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".
[FFmpeg-devel] [PATCH 1/3] avutil/tests/lzo: remove timer macros
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
libavutil/tests/lzo.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavutil/tests/lzo.c b/libavutil/tests/lzo.c
index 0147ab5c1d..a5655dbfc5 100644
--- a/libavutil/tests/lzo.c
+++ b/libavutil/tests/lzo.c
@@ -55,7 +55,6 @@ int main(int argc, char *argv[]) {
} else
lzo1x_999_compress(orig, s, comp, &clen, tmp);
for (i = 0; i < 300; i++) {
-START_TIMER
inlen = clen; outlen = MAXSZ;
#if BENCHMARK_LIBLZO_SAFE
if (lzo1x_decompress_safe(comp, inlen, decomp, &outlen, NULL))
@@ -65,7 +64,6 @@ START_TIMER
if (av_lzo1x_decode(decomp, &outlen, comp, &inlen))
#endif
av_log(NULL, AV_LOG_ERROR, "decompression error\n");
-STOP_TIMER("lzod")
}
if (memcmp(orig, decomp, s))
av_log(NULL, AV_LOG_ERROR, "decompression incorrect\n");
--
2.31.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 3/3] avutil/tests/audio_fifo: explicitly include config.h
From: Matthieu Patou Needed for HAVE_BIGENDIAN Suggested-by: ffm...@fb.com Signed-off-by: James Almer --- libavutil/tests/audio_fifo.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavutil/tests/audio_fifo.c b/libavutil/tests/audio_fifo.c index e107166eb1..c9d6bfc7db 100644 --- a/libavutil/tests/audio_fifo.c +++ b/libavutil/tests/audio_fifo.c @@ -15,6 +15,7 @@ * License along with FFmpeg; if not, write to the Free Software * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA */ +#include "config.h" #include #include -- 2.31.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] checkasm/vp9dsp: rename the iszero function to is_zero
From: Matthieu Patou
The function name iszero() may collide with a function in glibc.
Suggested-by: ffm...@fb.com
Signed-off-by: James Almer
---
tests/checkasm/vp9dsp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/tests/checkasm/vp9dsp.c b/tests/checkasm/vp9dsp.c
index 99c023899f..44b02d60a2 100644
--- a/tests/checkasm/vp9dsp.c
+++ b/tests/checkasm/vp9dsp.c
@@ -294,7 +294,7 @@ static int copy_subcoefs(int16_t *out, const int16_t *in,
enum TxfmMode tx,
return eob;
}
-static int iszero(const int16_t *c, int sz)
+static int is_zero(const int16_t *c, int sz)
{
int n;
@@ -362,8 +362,8 @@ static void check_itxfm(void)
call_ref(dst0, sz * SIZEOF_PIXEL, subcoef0, eob);
call_new(dst1, sz * SIZEOF_PIXEL, subcoef1, eob);
if (memcmp(dst0, dst1, sz * sz * SIZEOF_PIXEL) ||
-!iszero(subcoef0, sz * sz * SIZEOF_COEF) ||
-!iszero(subcoef1, sz * sz * SIZEOF_COEF))
+!is_zero(subcoef0, sz * sz * SIZEOF_COEF) ||
+!is_zero(subcoef1, sz * sz * SIZEOF_COEF))
fail();
bench_new(dst, sz * SIZEOF_PIXEL, coef, eob);
--
2.31.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/2] avutil/samplefmt: remove outdated comment
av_samples_fill_arrays() has been returning the minimum required buffer size for a while now. Signed-off-by: James Almer --- libavutil/samplefmt.h | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavutil/samplefmt.h b/libavutil/samplefmt.h index 8cd43ae856..f270199195 100644 --- a/libavutil/samplefmt.h +++ b/libavutil/samplefmt.h @@ -195,9 +195,8 @@ int av_samples_get_buffer_size(int *linesize, int nb_channels, int nb_samples, * @param nb_samples the number of samples in a single channel * @param sample_fmt the sample format * @param alignbuffer size alignment (0 = default, 1 = no alignment) - * @return >=0 on success or a negative error code on failure - * @todo return minimum size in bytes required for the buffer in case - * of success at the next bump + * @return minimum size in bytes required for the buffer on success, + * or a negative error code on failure */ int av_samples_fill_arrays(uint8_t **audio_data, int *linesize, const uint8_t *buf, -- 2.31.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/2] avutil/samplefmt: don't add offsets to NULL pointers
Signed-off-by: James Almer --- libavutil/samplefmt.c | 13 ++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/libavutil/samplefmt.c b/libavutil/samplefmt.c index fc077f6444..c7428940e1 100644 --- a/libavutil/samplefmt.c +++ b/libavutil/samplefmt.c @@ -160,13 +160,20 @@ int av_samples_fill_arrays(uint8_t **audio_data, int *linesize, if (buf_size < 0) return buf_size; +if (linesize) +*linesize = line_size; + +memset(audio_data, 0, planar + ? sizeof(*audio_data) * nb_channels + : sizeof(*audio_data)); + +if (!buf) +return buf_size; + audio_data[0] = (uint8_t *)buf; for (ch = 1; planar && ch < nb_channels; ch++) audio_data[ch] = audio_data[ch-1] + line_size; -if (linesize) -*linesize = line_size; - return buf_size; } -- 2.31.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] libavcodec: r12b decoder
Failed to apply, what is the exact way you want the patch? Kind regards, Dennis Fleurbaaij +31 (0) 6 54 21 5365 On Sat, Jun 5, 2021 at 6:12 PM Valerii Zapodovnikov wrote: > That did work, cool. > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/capucmebbw-rkt3mw5berkg3cqa+-akryfahclfc36mh2ybn...@mail.gmail.com/ > > BTW, will have to look into patchwork's patchwork (D:)) whether they fixed > .patch extensions. Apparently not. Also everything in "Re:" cannot contain > a patch. Ha. > ___ > 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".
[FFmpeg-devel] [PATCH v2] Revert "avformat/dashenc: Disable writing CODECS tag for HEVC streams"
This reverts commit d6d407d2d758b404af0ce6a8ff46bf164db020a1.
Hack not needed after a2b1dd0ce301450a47c972745a6b33c4c273aa5d.
Will fix #7480 and #8904.
This will include e.g. CODECS="hvc1.2.4.L123.B0" into m3u8.
Signed-off-by: Valerii Zapodovnikov
---
libavformat/dashenc.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 810ab22416..8a626c15a4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1312,7 +1312,6 @@ static int write_manifest(AVFormatContext *s, int final)
AVStream *st = s->streams[i];
OutputStream *os = &c->streams[i];
char *agroup = NULL;
-char *codec_str_ptr = NULL;
int stream_bitrate = os->muxer_overhead;
if (os->bit_rate > 0)
stream_bitrate += os->bit_rate;
@@ -1331,13 +1330,10 @@ static int write_manifest(AVFormatContext *s, int final)
av_strlcat(codec_str, ",", sizeof(codec_str));
av_strlcat(codec_str, audio_codec_str, sizeof(codec_str));
}
-if (st->codecpar->codec_id != AV_CODEC_ID_HEVC) {
-codec_str_ptr = codec_str;
-}
get_hls_playlist_name(playlist_file, sizeof(playlist_file),
NULL, i);
ff_hls_write_stream_info(st, c->m3u8_out, stream_bitrate,
playlist_file, agroup,
- codec_str_ptr, NULL, NULL);
+ codec_str, NULL, NULL);
}
} else {
--
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] libavcodec: r12b decoder
>From a distance, the patch looks like its in the correct format and everything (generated by git format-patch, right?). Is it against current HEAD? There may be a conflict On Mon, Jun 7, 2021 at 8:02 AM Dennis Fleurbaaij wrote: > > Failed to apply, what is the exact way you want the patch? > > Kind regards, > > Dennis Fleurbaaij > +31 (0) 6 54 21 5365 > > > On Sat, Jun 5, 2021 at 6:12 PM Valerii Zapodovnikov > wrote: > > > That did work, cool. > > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/capucmebbw-rkt3mw5berkg3cqa+-akryfahclfc36mh2ybn...@mail.gmail.com/ > > > > BTW, will have to look into patchwork's patchwork (D:)) whether they fixed > > .patch extensions. Apparently not. Also everything in "Re:" cannot contain > > a patch. Ha. > > ___ > > 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". ___ 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".
