Re: [FFmpeg-devel] [PATCH v2] lavu/thread: add support for setting thread name on *bsd and solaris
On 2024-01-07 12:55 a.m., Brad Smith wrote:
lavu/thread: add support for setting thread name on *bsd and solaris
FreeBSD/DragonFly/Solaris use pthread_setname_np(). OpenBSD uses
pthread_set_name_np().
Signed-off-by: Brad Smith
---
configure | 10 ++
libavutil/thread.h | 14 --
2 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 0b5e83bd20..67660b6292 100755
--- a/configure
+++ b/configure
@@ -2239,6 +2239,7 @@ HEADERS_LIST="
opencv2_core_core_c_h
OpenGL_gl3_h
poll_h
+pthread_np_h
sys_param_h
sys_resource_h
sys_select_h
@@ -2341,6 +2342,8 @@ SYSTEM_FUNCS="
posix_memalign
prctl
pthread_cancel
+pthread_set_name_np
+pthread_setname_np
sched_getaffinity
SecItemImport
SetConsoleTextAttribute
@@ -6523,6 +6526,7 @@ check_headers malloc.h
check_headers mftransform.h
check_headers net/udplite.h
check_headers poll.h
+check_headers pthread_np.h
check_headers sys/param.h
check_headers sys/resource.h
check_headers sys/select.h
@@ -6691,6 +6695,12 @@ if ! disabled pthreads && ! enabled w32threads && !
enabled os2threads; then
if enabled pthreads; then
check_builtin sem_timedwait semaphore.h "sem_t *s; sem_init(s,0,0);
sem_timedwait(s,0); sem_destroy(s)" $pthreads_extralibs
check_func pthread_cancel $pthreads_extralibs
+hdrs=pthread.h
+if enabled pthread_np_h; then
+hdrs="$hdrs pthread_np.h"
+fi
+check_lib pthread_set_name_np "$hdrs" pthread_set_name_np -lpthread
+check_lib pthread_setname_np "$hdrs" pthread_setname_np -lpthread
fi
fi
diff --git a/libavutil/thread.h b/libavutil/thread.h
index 2ded498c89..fa74dd2ea7 100644
--- a/libavutil/thread.h
+++ b/libavutil/thread.h
@@ -26,6 +26,8 @@
#if HAVE_PRCTL
#include
+#elif (HAVE_PTHREAD_SETNAME_NP || HAVE_PTHREAD_SET_NAME_NP) &&
HAVE_PTHREAD_NP_H
+#include
#endif
#include "error.h"
@@ -213,11 +215,19 @@ static inline int ff_thread_once(char *control, void
(*routine)(void))
static inline int ff_thread_setname(const char *name)
{
+int ret = 0;
+
#if HAVE_PRCTL
-return AVERROR(prctl(PR_SET_NAME, name));
+ret = AVERROR(prctl(PR_SET_NAME, name));
+#elif HAVE_PTHREAD_SETNAME_NP
+ret = AVERROR(pthread_setname_np(pthread_self(), name));
+#elif HAVE_PTHREAD_SET_NAME_NP
+pthread_set_name_np(pthread_self(), name);
+#else
+ret = AVERROR(ENOSYS);
#endif
-return AVERROR(ENOSYS);
+return ret;
}
#endif /* AVUTIL_THREAD_H */
ping.
___
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 2/2] doc/ffmpeg: update the documentation about vaapi device creation
On Sa, 2024-01-06 at 11:54 +0100, Stefano Sabatini wrote:
> On date Friday 2024-01-05 10:33:52 +0800, Xiang, Haihao wrote:
> > From: Haihao Xiang
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > doc/ffmpeg.texi | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index f095f402bd..8fb165c5df 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -1385,6 +1385,29 @@ If not specified, it will attempt to open the default
> > X11 display (@emph{$DISPLA
> > and then the first DRM render node (@emph{/dev/dri/renderD128}), or the
> > default
> > DirectX adapter on Windows.
> >
> > +The following options are recognized:
> > +@table @option
> > +@item kernel_driver
> > +When @var{device} is not specified, use this option to specify the name of
> > the kernel
>
> > +driver associated with the desired device. This option is only available
> > when
> > +@emph{libdrm} works on Linux.
>
> Optional: might be good to specify a method to verify this condition.
>
> > +@end table
> > +
> > +Examples:
> > +@table @emph
> > +@item -init_hw_device vaapi
> > +Create a vaapi device on the default device
>
> missing final dot here and below
>
> > +
> > +@item -init_hw_device vaapi:/dev/dri/renderD129
> > +Create a vaapi device on DRM render node /dev/dri/renderD129
> > +
> > +@item -init_hw_device vaapi:1
> > +Create a vaapi device on DirectX adapter 1
> > +
> > +@item -init_hw_device vaapi:,kernel_driver=i915
> > +Create a vaapi device on a device associated with kernel driver @samp{i915}
> > +@end table
> > +
>
> Looks good otherwise (but again, since hwaccels are probably
> independent from ffmpeg they should be probably moved to a dedicated
> manual).
>
Thanks for your comment, I updated this patch in v3
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319689.html
BRs
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".
Re: [FFmpeg-devel] [PATCH v2 1/2] doc/ffmpeg: update the documentation about qsv device creation
On Sa, 2024-01-06 at 11:51 +0100, Stefano Sabatini wrote:
> On date Friday 2024-01-05 10:33:51 +0800, Xiang, Haihao wrote:
> > From: Haihao Xiang
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > doc/ffmpeg.texi | 26 --
> > 1 file changed, 24 insertions(+), 2 deletions(-)
> >
> > diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
> > index 7246a46d2f..f095f402bd 100644
> > --- a/doc/ffmpeg.texi
> > +++ b/doc/ffmpeg.texi
> > @@ -1406,16 +1406,38 @@ If not specified, @samp{auto_any} is used.
> > platform-appropriate subdevice (@samp{dxva2} or @samp{d3d11va} or
> > @samp{vaapi}) and then deriving a
> > QSV device from that.)
> >
> > -Alternatively, @samp{child_device_type} helps to choose platform-
> > appropriate subdevice type.
> > -On Windows @samp{d3d11va} is used as default subdevice type.
> > +The following options are recognized:
> > +@table @option
>
> > +@item child_device
> > +Specify a DRM render node on Linux or DirectX adapter on Windows
>
> missing dot at the end of complete sentence, here and below
>
> > +@item child_device_type
> > +Choose platform-appropriate subdevice type. On Windows @samp{d3d11va} is
> > used
> > +as default subdevice type.
>
> Is this needed for non-Windows platforms?
>
> > +@end table
> >
> > Examples:
> > @table @emph
> > +@item -init_hw_device qsv:hw,child_device=/dev/dri/renderD129
>
> > +Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DRM render node
> > /dev/dri/renderD129
>
> You can quote the device with @file{/dev/dri/renderD129}.
>
> > +
> > +@item -init_hw_device qsv:hw,child_device=1
> > +Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DirectX adapter 1. The
> > subdevice
> > +type is @samp{d3d11va} if @code{--enable-libvpl} is specified at
> > configuration time, the
> > +subdevice type is @samp{dxva2} if @code{--enable-libmfx} is specified at
> > configuration time.
> > +
> > @item -init_hw_device qsv:hw,child_device_type=d3d11va
> > Choose the GPU subdevice with type @samp{d3d11va} and create QSV device
> > with @samp{MFX_IMPL_HARDWARE}.
> >
> > @item -init_hw_device qsv:hw,child_device_type=dxva2
> > Choose the GPU subdevice with type @samp{dxva2} and create QSV device with
> > @samp{MFX_IMPL_HARDWARE}.
> > +
> > +@item -init_hw_device qsv:hw,child_device=1,child_device_type=d3d11va
> > +Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DirectX adapter 1 with
> > subdevice type @samp{d3d11va}
> > +
> > +@item -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device
> > qsv=hw1@va
> > +Create a VAAPI device called @samp{va} on /dev/dri/renderD129, then derive
> > a QSV device called @samp{hw1}
> > +from device @samp{va}
>
> Looks good otherwise.
>
> BTW, do you know why all hwaccels are not documented in a dedicated
> file (hwaccels.texi or something)?
Thanks for your comment, I updated the patch in v3
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-January/319688.html .
BTW I don't know why there isn't a dedicated file for hwaccels.
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] [PATCH v3 2/2] doc/ffmpeg: update the documentation about vaapi device creation
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
doc/ffmpeg.texi | 23 +++
1 file changed, 23 insertions(+)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index d086d2e554..bfb3772654 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1385,6 +1385,29 @@ If not specified, it will attempt to open the default
X11 display (@emph{$DISPLA
and then the first DRM render node (@emph{/dev/dri/renderD128}), or the default
DirectX adapter on Windows.
+The following options are recognized:
+@table @option
+@item kernel_driver
+When @var{device} is not specified, use this option to specify the name of the
kernel
+driver associated with the desired device. This option is available only when
+the hardware acceleration method @emph{drm} and @emph{vaapi} are enabled.
+@end table
+
+Examples:
+@table @emph
+@item -init_hw_device vaapi
+Create a vaapi device on the default device.
+
+@item -init_hw_device vaapi:/dev/dri/renderD129
+Create a vaapi device on DRM render node @file{/dev/dri/renderD129}.
+
+@item -init_hw_device vaapi:1
+Create a vaapi device on DirectX adapter 1.
+
+@item -init_hw_device vaapi:,kernel_driver=i915
+Create a vaapi device on a device associated with kernel driver @samp{i915}.
+@end table
+
@item vdpau
@var{device} is an X11 display name.
If not specified, it will attempt to open the default X11 display
(@emph{$DISPLAY}).
--
2.34.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 v3 1/2] doc/ffmpeg: update the documentation about qsv device creation
From: Haihao Xiang
Signed-off-by: Haihao Xiang
---
doc/ffmpeg.texi | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 7246a46d2f..d086d2e554 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1406,16 +1406,38 @@ If not specified, @samp{auto_any} is used.
platform-appropriate subdevice (@samp{dxva2} or @samp{d3d11va} or
@samp{vaapi}) and then deriving a
QSV device from that.)
-Alternatively, @samp{child_device_type} helps to choose platform-appropriate
subdevice type.
-On Windows @samp{d3d11va} is used as default subdevice type.
+The following options are recognized:
+@table @option
+@item child_device
+Specify a DRM render node on Linux or DirectX adapter on Windows.
+@item child_device_type
+Choose platform-appropriate subdevice type. On Windows @samp{d3d11va} is used
+as default subdevice type when @code{--enable-libvpl} is specified at
configuration time,
+@samp{dxva2} is used as default subdevice type when @code{--enable-libmfx} is
specified at
+configuration time. On Linux user can use @samp{vaapi} only as subdevice type.
+@end table
Examples:
@table @emph
+@item -init_hw_device qsv:hw,child_device=/dev/dri/renderD129
+Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DRM render node
@file{/dev/dri/renderD129}.
+
+@item -init_hw_device qsv:hw,child_device=1
+Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DirectX adapter 1.
+
@item -init_hw_device qsv:hw,child_device_type=d3d11va
Choose the GPU subdevice with type @samp{d3d11va} and create QSV device with
@samp{MFX_IMPL_HARDWARE}.
@item -init_hw_device qsv:hw,child_device_type=dxva2
Choose the GPU subdevice with type @samp{dxva2} and create QSV device with
@samp{MFX_IMPL_HARDWARE}.
+
+@item -init_hw_device qsv:hw,child_device=1,child_device_type=d3d11va
+Create a QSV device with @samp{MFX_IMPL_HARDWARE} on DirectX adapter 1 with
subdevice type @samp{d3d11va}.
+
+@item -init_hw_device vaapi=va:/dev/dri/renderD129 -init_hw_device
qsv=hw1@@@var{va}
+Create a VAAPI device called @samp{va} on @file{/dev/dri/renderD129}, then
derive a QSV device called @samp{hw1}
+from device @samp{va}.
+
@end table
@item opencl
--
2.34.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] avformat: move internal stream related functions and structs to a separate header
Signed-off-by: James Almer
---
libavformat/Makefile | 1 +
libavformat/avformat.c| 171
libavformat/demux.h | 29 ---
libavformat/internal.h| 319 +---
libavformat/stream.c | 196 ++
libavformat/stream_internal.h | 376 ++
6 files changed, 574 insertions(+), 518 deletions(-)
create mode 100644 libavformat/stream.c
create mode 100644 libavformat/stream_internal.h
diff --git a/libavformat/Makefile b/libavformat/Makefile
index dcc99eeac4..6dd9b10e6b 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -27,6 +27,7 @@ OBJS = allformats.o \
riff.o \
sdp.o\
seek.o \
+ stream.o \
url.o\
utils.o \
version.o\
diff --git a/libavformat/avformat.c b/libavformat/avformat.c
index 882927f7b1..596d1dfb92 100644
--- a/libavformat/avformat.c
+++ b/libavformat/avformat.c
@@ -24,7 +24,6 @@
#include "libavutil/avstring.h"
#include "libavutil/channel_layout.h"
#include "libavutil/frame.h"
-#include "libavutil/iamf.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/mem.h"
#include "libavutil/opt.h"
@@ -32,89 +31,13 @@
#include "libavutil/samplefmt.h"
#include "libavcodec/avcodec.h"
#include "libavcodec/codec.h"
-#include "libavcodec/bsf.h"
#include "libavcodec/codec_desc.h"
-#include "libavcodec/packet_internal.h"
#include "avformat.h"
#include "avio.h"
#include "demux.h"
#include "mux.h"
#include "internal.h"
-void ff_free_stream(AVStream **pst)
-{
-AVStream *st = *pst;
-FFStream *const sti = ffstream(st);
-
-if (!st)
-return;
-
-#if FF_API_AVSTREAM_SIDE_DATA
-FF_DISABLE_DEPRECATION_WARNINGS
-for (int i = 0; i < st->nb_side_data; i++)
-av_freep(>side_data[i].data);
-av_freep(>side_data);
-FF_ENABLE_DEPRECATION_WARNINGS
-#endif
-
-if (st->attached_pic.data)
-av_packet_unref(>attached_pic);
-
-av_parser_close(sti->parser);
-avcodec_free_context(>avctx);
-av_bsf_free(>bsfc);
-av_freep(>priv_pts);
-av_freep(>index_entries);
-av_freep(>probe_data.buf);
-
-av_bsf_free(>extract_extradata.bsf);
-
-if (sti->info) {
-av_freep(>info->duration_error);
-av_freep(>info);
-}
-
-av_dict_free(>metadata);
-avcodec_parameters_free(>codecpar);
-av_freep(>priv_data);
-
-av_freep(pst);
-}
-
-void ff_free_stream_group(AVStreamGroup **pstg)
-{
-AVStreamGroup *stg = *pstg;
-
-if (!stg)
-return;
-
-av_freep(>streams);
-av_dict_free(>metadata);
-av_freep(>priv_data);
-switch (stg->type) {
-case AV_STREAM_GROUP_PARAMS_IAMF_AUDIO_ELEMENT: {
-av_iamf_audio_element_free(>params.iamf_audio_element);
-break;
-}
-case AV_STREAM_GROUP_PARAMS_IAMF_MIX_PRESENTATION: {
-av_iamf_mix_presentation_free(>params.iamf_mix_presentation);
-break;
-}
-default:
-break;
-}
-
-av_freep(pstg);
-}
-
-void ff_remove_stream(AVFormatContext *s, AVStream *st)
-{
-av_assert0(s->nb_streams>0);
-av_assert0(s->streams[ s->nb_streams - 1 ] == st);
-
-ff_free_stream(>streams[ --s->nb_streams ]);
-}
-
/* XXX: suppress the packet queue */
void ff_flush_packet_queue(AVFormatContext *s)
{
@@ -247,68 +170,6 @@ uint8_t *av_stream_new_side_data(AVStream *st, enum
AVPacketSideDataType type,
FF_ENABLE_DEPRECATION_WARNINGS
#endif
-/**
- * Copy all stream parameters from source to destination stream, with the
- * exception of the index field, which is usually set by avformat_new_stream().
- *
- * @param dst pointer to destination AVStream
- * @param src pointer to source AVStream
- * @return >=0 on success, AVERROR code on error
- */
-static int stream_params_copy(AVStream *dst, const AVStream *src)
-{
-int ret;
-
-dst->id = src->id;
-dst->time_base = src->time_base;
-dst->start_time = src->start_time;
-dst->duration= src->duration;
-dst->nb_frames = src->nb_frames;
-dst->disposition = src->disposition;
-dst->discard = src->discard;
-dst->sample_aspect_ratio = src->sample_aspect_ratio;
-dst->avg_frame_rate = src->avg_frame_rate;
-dst->event_flags = src->event_flags;
-dst->r_frame_rate= src->r_frame_rate;
-dst->pts_wrap_bits = src->pts_wrap_bits;
-
-av_dict_free(>metadata);
-ret = av_dict_copy(>metadata, src->metadata, 0);
-if (ret < 0)
-return ret;
-
-ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
-if (ret < 0)
-return ret;
-
-av_packet_unref(>attached_pic);
-if (src->attached_pic.data) {
-ret = av_packet_ref(>attached_pic, >attached_pic);
-if (ret < 0)
-return ret;
-}
-
-return 0;
-}
-
Re: [FFmpeg-devel] [PATCH] avutil/eval: Use even better PRNG
On Sun, Jan 14, 2024 at 03:14:23PM +0100, Stefano Sabatini wrote:
> On date Saturday 2024-01-13 04:51:06 +0100, Michael Niedermayer wrote:
> > This is the 64bit version of Chris Doty-Humphreys SFC64
> >
> > Compared to the LCGs these produce much better quality numbers.
> > Compared to LFGs this needs less state. (our LFG has 224 byte
> > state for its 32bit version) this has 32byte state
> > Also the initialization for our LFG is slower.
> > This is also much faster than KISS or PCG.
> >
> > This commit replaces the broken LCG used before.
> > (broken as it had only a period ~200M due to being put in a double)
> >
> > This changes the output from random() which is why libswresample.mak
> > is updated, update was done using the command in libswresample.mak
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/eval.c | 24 +++-
> > libavutil/sfc64.h| 85 ++
> > tests/fate/libswresample.mak | 208 +--
> > tests/ref/fate/eval | 2 +-
> > 4 files changed, 210 insertions(+), 109 deletions(-)
> > create mode 100644 libavutil/sfc64.h
> >
> > diff --git a/libavutil/eval.c b/libavutil/eval.c
> > index dc6b3697bc2..349015d4fa3 100644
> > --- a/libavutil/eval.c
> > +++ b/libavutil/eval.c
> > @@ -35,6 +35,7 @@
> > #include "internal.h"
> > #include "log.h"
> > #include "mathematics.h"
> > +#include "sfc64.h"
> > #include "time.h"
> > #include "avstring.h"
> > #include "timer.h"
> > @@ -55,6 +56,7 @@ typedef struct Parser {
> > void *log_ctx;
> > #define VARS 10
> > double *var;
> > +FFSFC64 *prng_state;
> > } Parser;
> >
> > static const AVClass eval_class = {
> > @@ -173,6 +175,7 @@ struct AVExpr {
> > } a;
> > struct AVExpr *param[3];
> > double *var;
> > +FFSFC64 *prng_state;
> > };
> >
> > static double etime(double v)
> > @@ -231,8 +234,14 @@ static double eval_expr(Parser *p, AVExpr *e)
> >
> > #define COMPUTE_NEXT_RANDOM()\
> > int idx = av_clip(eval_expr(p, e->param[0]), 0, VARS-1); \
> > -uint64_t r = isnan(p->var[idx]) ? 0 : p->var[idx]; \
> > -r = r * 1664525 + 1013904223;\
> > +FFSFC64 *s = p->prng_state + idx;\
> > +uint64_t r; \
> > + \
> > +if (!s->counter) { \
> > +r = isnan(p->var[idx]) ? 0 : p->var[idx];\
> > +ff_sfc64_init(s, r, r, r, 12); \
> > +}\
> > +r = ff_sfc64_get(s); \
> > p->var[idx] = r; \
> >
> > case e_random: {
> > @@ -329,7 +338,11 @@ static double eval_expr(Parser *p, AVExpr *e)
> > case e_div: return e->value * (d2 ? (d / d2) : d *
> > INFINITY);
> > case e_add: return e->value * (d + d2);
> > case e_last:return e->value * d2;
> > -case e_st : return e->value * (p->var[av_clip(d, 0,
> > VARS-1)]= d2);
> > +case e_st : {
> > +int index = av_clip(d, 0, VARS-1);
> > +p->prng_state[index].counter = 0;
> > +return e->value * (p->var[index]= d2);
> > +}
> > case e_hypot:return e->value * hypot(d, d2);
> > case e_atan2:return e->value * atan2(d, d2);
> > case e_bitand: return isnan(d) || isnan(d2) ? NAN :
> > e->value * ((long int)d & (long int)d2);
> > @@ -349,6 +362,7 @@ void av_expr_free(AVExpr *e)
> > av_expr_free(e->param[1]);
> > av_expr_free(e->param[2]);
> > av_freep(>var);
> > +av_freep(>prng_state);
> > av_freep();
> > }
> >
> > @@ -736,7 +750,8 @@ int av_expr_parse(AVExpr **expr, const char *s,
> > goto end;
> > }
> > e->var= av_mallocz(sizeof(double) *VARS);
> > -if (!e->var) {
> > +e->prng_state = av_mallocz(sizeof(*e->prng_state) *VARS);
> > +if (!e->var || !e->prng_state) {
> > ret = AVERROR(ENOMEM);
> > goto end;
> > }
> > @@ -778,6 +793,7 @@ double av_expr_eval(AVExpr *e, const double
> > *const_values, void *opaque)
> > {
> > Parser p = { 0 };
> > p.var= e->var;
> > +p.prng_state= e->prng_state;
> >
> > p.const_values = const_values;
> > p.opaque = opaque;
> > diff --git a/libavutil/sfc64.h b/libavutil/sfc64.h
> > new file mode 100644
> > index 000..05f1e84cc68
> > --- /dev/null
> > +++ b/libavutil/sfc64.h
> > @@ -0,0 +1,85 @@
> > +/*
> > + * Copyright (c) 2024 Michael Niedermayer
> > + *
> > + * This file is part of FFmpeg.
> > + *
> >
Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/rtsp: Send mode=record instead of mode=receive in Transport header
On Mon, Jan 15, 2024 at 10:37:25PM +0200, Paul Orlyk wrote: > Fixes server compatibility issues with rtspclientsink GStreamer plugin. > > > From specification: > RFC 7826 "Real-Time Streaming Protocol Version 2.0" > (https://datatracker.ietf.org/doc/html/rfc7826), section 18.54: >mode: The mode parameter indicates the methods to be supported for > this session. The currently defined valid value is "PLAY". If > not provided, the default is "PLAY". The "RECORD" value was > defined in RFC 2326; in this specification, it is unspecified > but reserved. RECORD and other values may be specified in the > future. > RFC 2326 "Real Time Streaming Protocol (RTSP)" > (https://datatracker.ietf.org/doc/html/rfc2326), section 12.39: >mode: > The mode parameter indicates the methods to be supported for > this session. Valid values are PLAY and RECORD. If not > provided, the default is PLAY. > > mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp: > Add listen mode'. > > For comparison, Wowza was used to push RTSP stream to. Both GStreamer and > FFmpeg had no issues. > Here is the capture of Wowza responding to SETUP request: > 200 OK > CSeq: 3 > Server: Wowza Streaming Engine 4.8.26+4 build20231212155517 > Cache-Control: no-cache > Expires: Mon, 15 Jan 2024 19:40:31 GMT > Transport: > RTP/AVP/UDP;unicast;client_port=11640-11641;mode=record;source=172.17.0.2;server_port=6976-6977 > Date: Mon, 15 Jan 2024 19:40:31 GMT > Session: 1401457689;timeout=60 > > Test setup: > Server: ffmpeg -loglevel trace -y -rtsp_flags listen -i > rtsp://0.0.0.0:30800/live.stream t.mp4 > FFmpeg client: ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v > libx264 -f rtsp rtsp://127.0.0.1:30800/live.stream > GStreamer client: gst-launch-1.0 videotestsrc is-live=true pattern=smpte > ! queue ! videorate ! videoscale ! > video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay > font-desc="Sans, 84" halignment=center valignment=center ! queue ! > videoconvert ! tee name=t t. ! x264enc bitrate=9000 pass=cbr > speed-preset=ultrafast byte-stream=false key-int-max=15 threads=1 ! > video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc ! voaacenc ! > queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink > location=rtsp://localhost:30800/live.stream > > Test results: > modified FFmpeg client -> stock server: ok > stock FFmpeg client-> modified server : ok > modified FFmpeg client -> modified server : ok > GStreamer client -> modified server : ok > > Signed-off-by: Paul Orlyk > --- > libavformat/rtspdec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Thats a nice commit message will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. 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] doc/utils: fix atan2 parameter order
On date Sunday 2024-01-14 19:40:48 +, ffmpeg-devel Mailing List wrote:
> The C library function double atan2(double y, double x) takes y as the first
> parameter and x as the second parameter.
>
> Signed-off-by: Haixia Shi
> ---
> doc/utils.texi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/doc/utils.texi b/doc/utils.texi
> index 0c4f146f4f..76e704fc3c 100644
> --- a/doc/utils.texi
> +++ b/doc/utils.texi
> @@ -815,7 +815,7 @@ Compute arcsine of @var{x}.
> @item atan(x)
> Compute arctangent of @var{x}.
>
> -@item atan2(x, y)
> +@item atan2(y, x)
> Compute principal value of the arc tangent of @var{y}/@var{x}.
Applied, 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".
Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/rtsp: Support mode field of Transport header being sent in upper case
On Mon, Jan 15, 2024 at 10:37:09PM +0200, Paul Orlyk wrote: > Fixes server compatibility issues with rtspclientsink GStreamer plugin > > Signed-off-by: Paul Orlyk > --- > libavformat/rtsp.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- 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] [PATCH v2] avutil/pixfmt: fix AV_PIX_FMT_RGB8 description
On Sun, Jan 14, 2024 at 09:58:52PM +0100, Diederick C. Niehorster wrote:
> On Sun, Jan 14, 2024 at 4:15 PM Jeffrey Knockel
> wrote:
> >
> > Previously AV_PIX_FMT_RGB8 was documented as "RGB 3:3:2,
> > (msb)2R 3G 3B(lsb)". While the RGB 3:3:2 part is correct, the latter
> > part should be: (msb)3R 3G 2B(lsb). This commit also updates the
> > format's pixdesc description to be (msb)3R 3G 2B(lsb).
> >
> > Signed-off-by: Jeffrey Knockel
> > ---
> > libavutil/pixdesc.c | 6 +++---
> > libavutil/pixfmt.h | 2 +-
> > 2 files changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> > index 0db4167934..f6d4d01460 100644
> > --- a/libavutil/pixdesc.c
> > +++ b/libavutil/pixdesc.c
> > @@ -530,9 +530,9 @@ static const AVPixFmtDescriptor
> > av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
> > .log2_chroma_w = 0,
> > .log2_chroma_h = 0,
> > .comp = {
> > -{ 0, 1, 0, 6, 2 },/* R */
> > -{ 0, 1, 0, 3, 3 },/* G */
> > -{ 0, 1, 0, 0, 3 },/* B */
> > +{ 0, 1, 0, 5, 3 },/* R */
> > +{ 0, 1, 0, 2, 3 },/* G */
> > +{ 0, 1, 0, 0, 2 },/* B */
> > },
> > .flags = AV_PIX_FMT_FLAG_RGB,
> > },
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index 58f9ad28bd..9c87571f49 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -83,7 +83,7 @@ enum AVPixelFormat {
> > AV_PIX_FMT_BGR8, ///< packed RGB 3:3:2, 8bpp, (msb)2B 3G 3R(lsb)
> > AV_PIX_FMT_BGR4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1B
> > 2G 1R(lsb), a byte contains two pixels, the first pixel in the byte is the
> > one composed by the 4 msb bits
> > AV_PIX_FMT_BGR4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1B 2G 1R(lsb)
> > -AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)2R 3G 3B(lsb)
> > +AV_PIX_FMT_RGB8, ///< packed RGB 3:3:2, 8bpp, (msb)3R 3G 2B(lsb)
> > AV_PIX_FMT_RGB4, ///< packed RGB 1:2:1 bitstream, 4bpp, (msb)1R
> > 2G 1B(lsb), a byte contains two pixels, the first pixel in the byte is the
> > one composed by the 4 msb bits
> > AV_PIX_FMT_RGB4_BYTE, ///< packed RGB 1:2:1, 8bpp, (msb)1R 2G 1B(lsb)
> > AV_PIX_FMT_NV12, ///< planar YUV 4:2:0, 12bpp, 1 plane for Y and
> > 1 plane for the UV components, which are interleaved (first byte U and the
> > following byte V)
> > --
> > 2.34.1
>
> LGTM.
> Tested. Without this patch, the output of avutil av_read_image_line2()
> is all wrong, with it applied it is correct.
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus
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: AVX512-capable laptop
Jan 15, 2024, 19:51 by kier...@obe.tv: >> >> If you think it's reasonable, you shouldn't block it. >> If you have conditions, you should concisely state them. >> If you think this is entirely unreasonable and falls outside of the scope >> of >> the project's donation funds, then I would expect you to apply the >> same pragmatic standards when it comes to future refund requests, >> be it personal choices such as parking and travel expenses. >> > > Your laptop choice is one of the most expensive in the market and likely > much more expensive than the laptop the majority of developers use. > Buy an 11th Gen Intel NUC and a cheap laptop and access it remotely. > Would you accept jamrial's proposal? It's around a thousand EUR, and it's essentially got the features of both. > By your own analogy you want SPI to pay for your First Class ticket from > London to New York when there are cheaper alternatives. > A ticket doesn't have durability. ___ 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] fftools/opt_common: show if muxer is device
---
fftools/opt_common.c | 28 +---
1 file changed, 21 insertions(+), 7 deletions(-)
diff --git a/fftools/opt_common.c b/fftools/opt_common.c
index f5b73c9f2f..e263a5297e 100644
--- a/fftools/opt_common.c
+++ b/fftools/opt_common.c
@@ -853,14 +853,23 @@ static int show_formats_devices(void *optctx, const char
*opt, const char *arg,
const char *last_name;
int is_dev;
-printf("%s\n"
- " D. = Demuxing supported\n"
- " .E = Muxing supported\n"
- " --\n", device_only ? "Devices:" : "File formats:");
+if (device_only) {
+printf("Devices:\n"
+ " D. = Demuxing supported\n"
+ " .E = Muxing supported\n"
+ " --\n");
+} else {
+printf("Formats:\n"
+ " D.. = Demuxing supported\n"
+ " .E. = Muxing supported\n"
+ " ..d = Is a device\n"
+ " ---\n");
+}
last_name = "000";
for (;;) {
int decode = 0;
int encode = 0;
+int device = 0;
const char *name = NULL;
const char *long_name = NULL;
@@ -875,6 +884,7 @@ static int show_formats_devices(void *optctx, const char
*opt, const char *arg,
name = ofmt->name;
long_name = ofmt->long_name;
encode= 1;
+device= is_dev;
}
}
}
@@ -889,20 +899,24 @@ static int show_formats_devices(void *optctx, const char
*opt, const char *arg,
name = ifmt->name;
long_name = ifmt->long_name;
encode= 0;
+device= is_dev;
}
-if (name && strcmp(ifmt->name, name) == 0)
+if (name && strcmp(ifmt->name, name) == 0) {
decode = 1;
+device = is_dev;
+}
}
}
if (!name)
break;
last_name = name;
-printf(" %c%c %-15s %s\n",
+printf(" %c%c%s %-15s %s\n",
decode ? 'D' : ' ',
encode ? 'E' : ' ',
+ device_only ? "" : (device ? "d" : " "),
name,
-long_name ? long_name:" ");
+long_name ? long_name : " ");
}
return 0;
}
--
2.34.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] doc/muxers/chromaprint: review and extend
In particular, apply formatting and consistency fixes and sort options
by name.
---
doc/muxers.texi | 45 -
1 file changed, 24 insertions(+), 21 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index eadcba690c..5e4ee40db4 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -889,41 +889,44 @@ It accepts a single codec2 audio stream.
@anchor{chromaprint}
@section chromaprint
+Chromaprint fingerprinter muxers.
-Chromaprint fingerprinter.
+To enable compilation of this filter you need to configure FFmpeg with
+@code{--enable-chromaprint}.
-This muxer feeds audio data to the Chromaprint library,
-which generates a fingerprint for the provided audio data. See
@url{https://acoustid.org/chromaprint}
+This muxer feeds audio data to the Chromaprint library, which
+generates a fingerprint for the provided audio data. See:
+@url{https://acoustid.org/chromaprint}
-It takes a single signed native-endian 16-bit raw audio stream of at most 2
channels.
+It takes a single signed native-endian 16-bit raw audio stream of at
+most 2 channels.
@subsection Options
-
@table @option
-@item silence_threshold
-Threshold for detecting silence. Range is from -1 to 32767, where -1 disables
-silence detection. Silence detection can only be used with version 3 of the
-algorithm.
-Silence detection must be disabled for use with the AcoustID service. Default
is -1.
-
-@item algorithm
-Version of algorithm to fingerprint with. Range is 0 to 4.
-Version 3 enables silence detection. Default is 1.
+@item algorithm @var{version}
+Select version of algorithm to fingerprint with. Range is @code{0} to
+@code{4}. Version @code{3} enables silence detection. Default is @code{1}.
-@item fp_format
+@item fp_format @var{format}
Format to output the fingerprint as. Accepts the following options:
-@table @samp
-@item raw
-Binary raw fingerprint
+@item base64
+Base64 compressed fingerprint @emph{(default)}
@item compressed
Binary compressed fingerprint
-@item base64
-Base64 compressed fingerprint @emph{(default)}
-
+@table @samp
+@item raw
+Binary raw fingerprint
@end table
+@item silence_threshold @var{threshold}
+Threshold for detecting silence. Range is from @code{-1} to
+@code{32767}, where @code{-1} disables silence detection. Silence
+detection can only be used with version @code{3} of the algorithm.
+
+Silence detection must be disabled for use with the AcoustID
+service. Default is @code{-1}.
@end table
@anchor{crc}
--
2.34.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] doc/muxers: add codec2
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 1bdd7d34d5..eadcba690c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -882,6 +882,11 @@ Apple CAF (Core Audio Format) muxer.
It accepts a single audio stream.
+@section codec2
+Codec2 audio audio muxer.
+
+It accepts a single codec2 audio stream.
+
@anchor{chromaprint}
@section chromaprint
--
2.34.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] doc/muxers: add caf
---
doc/muxers.texi | 5 +
1 file changed, 5 insertions(+)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index e91a4f8e45..1bdd7d34d5 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -877,6 +877,11 @@ G.729 (.bit) file format muxer.
It accepts a single G.729 audio stream.
+@section caf
+Apple CAF (Core Audio Format) muxer.
+
+It accepts a single audio stream.
+
@anchor{chromaprint}
@section chromaprint
--
2.34.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] rcwtenc: add sub-rcwt fate test ref
Looks like someone has pushed a simplified version of this patch, this is not needed anymore. Thanks. On Sun, Jan 14, 2024 at 11:20 PM Marth64 wrote: > Great, thank you for the confirmation. > > On Sun, Jan 14, 2024 at 11:06 PM Xiang, Haihao > wrote: > >> On So, 2024-01-14 at 22:38 -0600, Marth64 wrote: >> > Resolves the issue. Patch generated with git format-patch and validated >> to >> > apply. >> > I reget any inconvenience this may have caused. Respectfully, >> > >> > Signed-off-by: Marth64 >> > --- >> > tests/ref/fate/sub-rcwt | 1 + >> > 1 file changed, 1 insertion(+) >> > create mode 100644 tests/ref/fate/sub-rcwt >> > >> > diff --git a/tests/ref/fate/sub-rcwt b/tests/ref/fate/sub-rcwt >> > new file mode 100644 >> > index 00..722cbe1c5b >> > --- /dev/null >> > +++ b/tests/ref/fate/sub-rcwt >> > @@ -0,0 +1 @@ >> > +d86f179094a5752d68aa97d82cf887b0 >> >> Thanks for your quick fix, it works well for me. >> >> BRs >> 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".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hello, I wanted to call out 2 issues that I think are bugs from this, and that I was able to trace to the exact commit. *#1: Concat filter issues: *A user from IRC support reported it, and I was able to successfully reproduce it. When using concat filter on multiple inputs alongside -ss (same file or different file), it doesn't work correctly: output EOF after the first segment. https://trac.ffmpeg.org/ticket/10803 *#2 Wrong duration reported muxing graphical subtitles: *After re-architecture, ffmpeg CLI is printing incorrect output time and/or N/A after a job when muxing video with graphical subtitles (have reproduced with DVD and DVB). Issue is exaggerated with subtitle streams that have long gap like forced subs. https://trac.ffmpeg.org/ticket/10792 Thank you for your time and this improvement. Respectfully, On Mon, Dec 11, 2023 at 3:06 AM Anton Khirnov wrote: > both should now be fixed in my tree > > -- > 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 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/4] avcodec/mdec: DC reading for STRv1 is like STRv2
On Mon, Jan 15, 2024 at 04:14:46PM +, aybe aybe wrote: > Hi! > > I just tried what you've suggested, using 150 and setting AVPacket->pts using > sector MSF as LBA. > > The results are somewhat mixed: > - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC > - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC can you send the patch for this plus links to one sample for both cases ? id like to take a look thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- 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: AVX512-capable laptop
On Mon, Jan 15, 2024 at 06:50:37PM +, Kieran Kunhya wrote: > > > > If you think it's reasonable, you shouldn't block it. > > If you have conditions, you should concisely state them. > > If you think this is entirely unreasonable and falls outside of the scope > > of > > the project's donation funds, then I would expect you to apply the > > same pragmatic standards when it comes to future refund requests, > > be it personal choices such as parking and travel expenses. > > > > Your laptop choice is one of the most expensive in the market and likely > much more expensive than the laptop the majority of developers use. > Buy an 11th Gen Intel NUC and a cheap laptop and access it remotely. > > By your own analogy you want SPI to pay for your First Class ticket from > London to New York when there are cheaper alternatives. I think Lynnes first choice was a ASUS vivo book what about this one ? https://geizhals.eu/asus-vivobook-14-f415ea-eb269-slate-grey-90nb0tt2-m03310-a2557528.html?hloc=at=de Its a small 14inch ASUS vivo book with 11th gen Intel, non glare IPS screen for 349€ it has only 8gb which is non upgtadeable the disk iam sure can be upgraded if needed or if you want a bigger notebook with upgradability to at least 16gb check these https://geizhals.de/?cmp=3061202=3025372=3009388=2894111=3083934=3027428=3081782=2986117=0 all below 500€ intel 11th gen or later, IPS screens Thx [...] -- 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".
[FFmpeg-devel] [PATCH v2 2/2] avformat/rtsp: Send mode=record instead of mode=receive in Transport header
Fixes server compatibility issues with rtspclientsink GStreamer plugin.
From specification:
RFC 7826 "Real-Time Streaming Protocol Version 2.0"
(https://datatracker.ietf.org/doc/html/rfc7826), section 18.54:
mode: The mode parameter indicates the methods to be supported for
this session. The currently defined valid value is "PLAY". If
not provided, the default is "PLAY". The "RECORD" value was
defined in RFC 2326; in this specification, it is unspecified
but reserved. RECORD and other values may be specified in the
future.
RFC 2326 "Real Time Streaming Protocol (RTSP)"
(https://datatracker.ietf.org/doc/html/rfc2326), section 12.39:
mode:
The mode parameter indicates the methods to be supported for
this session. Valid values are PLAY and RECORD. If not
provided, the default is PLAY.
mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp: Add
listen mode'.
For comparison, Wowza was used to push RTSP stream to. Both GStreamer and
FFmpeg had no issues.
Here is the capture of Wowza responding to SETUP request:
200 OK
CSeq: 3
Server: Wowza Streaming Engine 4.8.26+4 build20231212155517
Cache-Control: no-cache
Expires: Mon, 15 Jan 2024 19:40:31 GMT
Transport:
RTP/AVP/UDP;unicast;client_port=11640-11641;mode=record;source=172.17.0.2;server_port=6976-6977
Date: Mon, 15 Jan 2024 19:40:31 GMT
Session: 1401457689;timeout=60
Test setup:
Server: ffmpeg -loglevel trace -y -rtsp_flags listen -i
rtsp://0.0.0.0:30800/live.stream t.mp4
FFmpeg client: ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v
libx264 -f rtsp rtsp://127.0.0.1:30800/live.stream
GStreamer client: gst-launch-1.0 videotestsrc is-live=true pattern=smpte ! queue !
videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay
font-desc="Sans, 84" halignment=center valignment=center ! queue ! videoconvert
! tee name=t t. ! x264enc bitrate=9000 pass=cbr speed-preset=ultrafast byte-stream=false
key-int-max=15 threads=1 ! video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc !
voaacenc ! queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink
location=rtsp://localhost:30800/live.stream
Test results:
modified FFmpeg client -> stock server: ok
stock FFmpeg client-> modified server : ok
modified FFmpeg client -> modified server : ok
GStreamer client -> modified server : ok
Signed-off-by: Paul Orlyk
---
libavformat/rtspdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index 39fd92fb66..d6a223cbc6 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -303,7 +303,7 @@ static int rtsp_read_setup(AVFormatContext *s, char* host,
char *controlurl)
rtsp_st->interleaved_min = request.transports[0].interleaved_min;
rtsp_st->interleaved_max = request.transports[0].interleaved_max;
snprintf(responseheaders, sizeof(responseheaders), "Transport: "
- "RTP/AVP/TCP;unicast;mode=receive;interleaved=%d-%d"
+ "RTP/AVP/TCP;unicast;mode=record;interleaved=%d-%d"
"\r\n", request.transports[0].interleaved_min,
request.transports[0].interleaved_max);
} else {
@@ -333,7 +333,7 @@ static int rtsp_read_setup(AVFormatContext *s, char* host,
char *controlurl)
localport = ff_rtp_get_local_rtp_port(rtsp_st->rtp_handle);
snprintf(responseheaders, sizeof(responseheaders), "Transport: "
- "RTP/AVP/UDP;unicast;mode=receive;source=%s;"
+ "RTP/AVP/UDP;unicast;mode=record;source=%s;"
"client_port=%d-%d;server_port=%d-%d\r\n",
host, request.transports[0].client_port_min,
request.transports[0].client_port_max, localport,
--
2.43.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 v2 1/2] avformat/rtsp: Support mode field of Transport header being sent in upper case
Fixes server compatibility issues with rtspclientsink GStreamer plugin
Signed-off-by: Paul Orlyk
---
libavformat/rtsp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index 583f5338e8..61e24a5c7a 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -1012,8 +1012,8 @@ static void rtsp_parse_transport(AVFormatContext *s,
if (*p == '=') {
p++;
get_word_sep(buf, sizeof(buf), ";, ", );
-if (!strcmp(buf, "record") ||
-!strcmp(buf, "receive"))
+if (!av_strcasecmp(buf, "record") ||
+!av_strcasecmp(buf, "receive"))
th->mode_record = 1;
}
}
--
2.43.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: AVX512-capable laptop
> > If you think it's reasonable, you shouldn't block it. > If you have conditions, you should concisely state them. > If you think this is entirely unreasonable and falls outside of the scope > of > the project's donation funds, then I would expect you to apply the > same pragmatic standards when it comes to future refund requests, > be it personal choices such as parking and travel expenses. > Your laptop choice is one of the most expensive in the market and likely much more expensive than the laptop the majority of developers use. Buy an 11th Gen Intel NUC and a cheap laptop and access it remotely. By your own analogy you want SPI to pay for your First Class ticket from London to New York when there are cheaper alternatives. Kieran ___ 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: AVX512-capable laptop
Jan 15, 2024, 17:02 by r...@remlab.net: > Le maanantaina 15. tammikuuta 2024, 16.59.40 EET Lynne a écrit : > >> I've been pinging this for a week now and he hasn't reiterated >> his position again or made it clearer. >> > > I think my position was clear. I don't see the point in rereiterating it > whilst we are evidently not going to reach an agreement. Besides, you have > previously complained that my explanations were unnecessarily long. > > But since you bring it up and to sum up, I find completely reasonable for > FFmpeg to provision hardware with the feature necessary to test your work, > such as AVX-512 and Vulkan video decoding. But: > 1) You already have been provided such hardware in the form of a desktop > computer (and I am told that it was extremely expensive). > 2) In general it makes more sense to get a desktop than a laptop for that > purpose. > I do not have AVX-512 capable system, and I iterated my concerns with using a shared machine in another thread. > Leaving aside those specific hardware requirements, I think it is completely > reasonable for you to have a laptop, as most of us probably do. But I also > think that it is not reasonable for the foundation to pay for personal > laptops. > It's a machine that I will use during travels too, specifically to do FFmpeg development on. We're not a foundation either, as far as I know - SPI manages the fund completely, with only the liaison needing to make a request, provided there's consensus. If you think it's reasonable, you shouldn't block it. If you have conditions, you should concisely state them. If you think this is entirely unreasonable and falls outside of the scope of the project's donation funds, then I would expect you to apply the same pragmatic standards when it comes to future refund requests, be it personal choices such as parking and travel expenses. ___ 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: AVX512-capable laptop
On Mon, Jan 15, 2024 at 05:10:03PM +0100, Nicolas George wrote: > Paul B Mahol (12024-01-15): > > Business? Why is then this discussion public? > > Face it, the FFmpeg Libre Software project that we loved contributing to > because it offered a space of freedom for like-minded hackers no longer > exists, this is now a shallow annex of the FFlabs company. No, FFmpeg is controlled by the general assembly, that you are a member of From the GA 6 people i would say are associated with FFlabs one of these 6 hates FFlabs as it is currently. 2 more i think got occasionally paid by FFlabs. (that is AFAIK it) OTOH 43 developers in the GA are unrelated to FFLabs so teh statement "is now a shallow annex of the FFlabs company." iam not sure what facts that would be based on ... That said, my wish was and is that FFlabs or a successor to FFlabs would pay all the major developers of FFmpeg more or less in the order of "git shortlog -s -n" excluding people inactive by choice. For what _they_ (the developers themselfs) would consider important to work on. This is not FFlabs today, for mainly 2 reasons. 1. Not enough money really to pay more people 2. To get money, FFlabs needs to work on what customers pay for. Now about your complaint about FFmpeg not being what you want. If you cannot find a consensus with others, there is the Technical Committee. You did not contact the TC. Also, iam not sure you are entirely correct with your memory FFmpeg certainly was more accepting with experimental, cutting edge and at the border of FFmpegs scope things. But I do not remember FFmpeg was ever accepting every random thing. What has changed is the size of the community, more people means there is a higher changce someone will disagree. If you have an idea that makes sense for FFmpeg please try contacting the Technical Committee if you cannot find a consensus. If that fails, then we can discuss further. But dont be so negative We can create a seperate branch where people can commit whatever they want or some other more accepting ruleset. But this makes no sense before an issue has even been raised with the TC Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin 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/2 v2] avformat/mov: improve HEIF parsing
On 1/9/2024 10:27 PM, James Almer wrote: Parse iprp and iinf boxes and children boxes to get the actual codec used (AV1 for avif, HEVC for heic), and properly export extradata and other properties in a generic way. The reference files for the avif tests are updated as the extradata is now exported. Based on a patch by Swaraj Hota. Co-authored-by: Swaraj Hota Signed-off-by: James Almer --- libavformat/isom.h| 19 +- libavformat/mov.c | 292 +- .../fate/mov-avif-demux-still-image-1-item| 2 +- .../mov-avif-demux-still-image-multiple-items | 2 +- 4 files changed, 228 insertions(+), 87 deletions(-) Will apply. ___ 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/4] avcodec/mdec: DC reading for STRv1 is like STRv2
Hi! I just tried what you've suggested, using 150 and setting AVPacket->pts using sector MSF as LBA. The results are somewhat mixed: - NTSC video: A/V synchronized but is now seen as 120 FPS by VLC - PAL video: A/V not synchronized anymore but still seen as 25 FPS by VLC Not sure about 150, we assume videos play at 2x CD-ROM, not 100% exact but is likely to be the case for 99% of them. -- Original Message -- >From "Michael Niedermayer via ffmpeg-devel" >mailto:ffmpeg-devel@ffmpeg.org>> To "FFmpeg development discussions and patches" mailto:ffmpeg-devel@ffmpeg.org>> Cc "Michael Niedermayer" mailto:mich...@niedermayer.cc>> Date 1/14/2024 9:38:06 PM Subject Re: [FFmpeg-devel] [PATCH 1/4] avcodec/mdec: DC reading for STRv1 is like STRv2 Hi aybe On Sat, Jan 13, 2024 at 02:28:52AM +, aybe aybe wrote: Here are the two STR files I have used when writing this patch: https://github.com/aybe/FFmpeg-PSX-STR-tests ok, i can confirm the version patch fixes these, i will apply it Fanatics would probably say that 30 FPS for NTSC is wrong (i.e. should be 29.97)... However, as the reversed-engineered docs in jpsxdec mentions, it is sort of impossible to figure out which value to snap to from how frames spans across CD-ROM sectors. The sector count per video frame always seem to juggle between two values, e.g. 6 sectors, then 7 sectors, rinse/repeat. i.e. it's never constant. Also, as one can see in the various code samples online on writing a PSX program that plays MDEC videos, it is the responsibility of the coder to present the frames on screen. i.e. there is not definitive way on how to do so, and even if there was, you can be sure some folks did not play by the rules back then. The only way to figure out how a movie was intended to be played is to reverse engineer a game to see what values they did cram in. In short, the computed frame rate is 99% good, not 100%. But for mere mortals, they are unlikely to notice it at all. Well, with the subset of samples i have, i dont feel confident that i could write and test timestamping/fps. The docuemnt you linked says "Data is read from the disc one sector at a time at either 75 sectors per second (single speed) or 150 sectors per second (double speed). The video and audio are spaced out over these sectors so they can be delivered at the appropriate times." what i would suggest to try is: avpriv_set_pts_info(st, 64, 1, 150); (or 75 for single speed) and then set AVPacket->pts to the sector number you never set fps, leave it to libavformat to figure it out. can you try that ? (i assume you have many samples to easily check) As for the movies in the samples repository, they are corrupt and FFmpeg fails at them, obviously. I figured these ones were by checking them in a hex-editor but also by loading them in https://github.com/m35/jpsxdec which has great logging. Not sure why these samples were corrupt in first instance, maybe it was intentional for testing? I can't tell. Thats very strange, anyone remembers where these samples are from originally ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued ___ 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: AVX512-capable laptop
Paul B Mahol (12024-01-15): > Business? Why is then this discussion public? Face it, the FFmpeg Libre Software project that we loved contributing to because it offered a space of freedom for like-minded hackers no longer exists, this is now a shallow annex of the FFlabs company. Regards, -- Nicolas George 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: AVX512-capable laptop
On Mon, Jan 15, 2024 at 5:01 PM Rémi Denis-Courmont wrote: > Le maanantaina 15. tammikuuta 2024, 16.06.32 EET Paul B Mahol a écrit : > > > I agree with Remi's objections to this. > > > > > > Kieran > > > > Poor and irrelevant devs object and want to keep money for themself. > > Neither of us are poor, which makes this defamatory. > > While we may subjectively be irrelavant, that is completely inappropriate > wording. For you reference, Nicolas was able to articulate that > characterisation in a much more business-compatible fashion. > Business? Why is then this discussion public? > > So this is being reported to the CC. > You cant report anything, it just show how poor you are. > > -- > 雷米‧德尼-库尔蒙 > http://www.remlab.net/ > > > > ___ > 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] Hardware purchase request: AVX512-capable laptop
Le maanantaina 15. tammikuuta 2024, 16.59.40 EET Lynne a écrit : > I've been pinging this for a week now and he hasn't reiterated > his position again or made it clearer. I think my position was clear. I don't see the point in rereiterating it whilst we are evidently not going to reach an agreement. Besides, you have previously complained that my explanations were unnecessarily long. But since you bring it up and to sum up, I find completely reasonable for FFmpeg to provision hardware with the feature necessary to test your work, such as AVX-512 and Vulkan video decoding. But: 1) You already have been provided such hardware in the form of a desktop computer (and I am told that it was extremely expensive). 2) In general it makes more sense to get a desktop than a laptop for that purpose. Leaving aside those specific hardware requirements, I think it is completely reasonable for you to have a laptop, as most of us probably do. But I also think that it is not reasonable for the foundation to pay for personal laptops. Maybe you need a laptop specifically to work on FFmpeg for whatever reason. Then a cheap laptop for remote access, as Michael suggested, sounds like a reasonable compromise to me. Nevertheless, I think that: - If your employment requires you to work away from your desktop a lot, then your employer should provide the laptop. - If you want to work from your couch or from the beach (figuratively), that is really on you. -- Rémi Denis-Courmont http://www.remlab.net/ ___ 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: AVX512-capable laptop
Le maanantaina 15. tammikuuta 2024, 16.06.32 EET Paul B Mahol a écrit : > > I agree with Remi's objections to this. > > > > Kieran > > Poor and irrelevant devs object and want to keep money for themself. Neither of us are poor, which makes this defamatory. While we may subjectively be irrelavant, that is completely inappropriate wording. For you reference, Nicolas was able to articulate that characterisation in a much more business-compatible fashion. So this is being reported to the CC. -- 雷米‧德尼-库尔蒙 http://www.remlab.net/ ___ 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: AVX512-capable laptop
Jan 15, 2024, 09:58 by kier...@obe.tv: > On Sun, 14 Jan 2024, 17:24 Lynne, wrote: > >> Jan 9, 2024, 19:57 by d...@lynne.ee: >> >> > Jan 3, 2024, 04:30 by d...@lynne.ee: >> > >> >> Jan 3, 2024, 04:04 by d...@lynne.ee: >> >> >> >>> Jan 3, 2024, 02:22 by jamr...@gmail.com: >> >>> >> On 1/2/2024 9:56 PM, Lynne wrote: >> >> > As some of you know, my laptop died nearly 2 years ago, and >> > I've been working on a desktop machine, which is currently a Zen 3. >> > AVX512 has become more popular in the meantime, with Zen 4 >> > and future AMD CPUs shipping with it, but currently, we have very >> > little AVX512. >> > In short, I'd like a machine which runs an AVX512-capable >> > AMD CPU, and as the world is opening up more and more, I'd >> > like for it to be portable. >> > >> > I've looked around a lot, but as Intel still has a firm monopoly, >> > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). >> > What I think I've settled for is an ASUS Vivobook Pro 15, with a >> > 7940HS CPU (the second least powerful Zen 4 mobile CPU), >> > >> >> 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure >> where you got second least powerful from. >> >> >> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) >> >> >>> >> >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake >> >>> (and AMD's mistake for making 4 versioning formats): >> >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors >> >>> >> >>> >> > currently trading for 1999.0 EUR on amazon.de. >> > >> > >> https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR >> > >> > The other alternative I've found is a Lenovo Legion 7 Pro, but >> > it's more expensive at 2399 EUR (currently seems temporarily >> > discounted due to the holidays). >> > >> >> I see a Lenovo Yoga Pro 7 available for 1099 EUR. >> https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ >> >> Same amount of RAM, screen resolution and storage, and a Ryzen 7. >> >> >>> >> >>> It's a good suggestion, but I have a better one, that's somewhat more >> expensive, >> >>> but has a better screen, better build quality, and is cheaper than the >> Vivobook: >> >>> >> >>> A Lenovo ThinkPad P14s Gen 4 with the following options: >> >>> - Windows 14 Home (if you don't pick Windows, the OLED display is not >> available for no reason) >> >>> - 32Gb of RAM >> >>> - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) >> >>> - 2880x1800 OLED monitor >> >>> - 4-cell battery (only 10 EUR more) >> >>> - English (EU) keyboard, without backlighting >> >>> >> >>> >> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 >> >>> >> >> >> >> Correction: link I pasted was for the P16s, not the P14s, this is the >> correct link: >> >> >> https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 >> >> >> > >> > Ping. So far I have one approval from Michael. >> > >> >> Ping. >> > > I agree with Remi's objections to this. > Which ones, or all of them in general? I've been pinging this for a week now and he hasn't reiterated his position again or made it clearer. ___ 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] checkasm: Test whether the native FFmpeg timers work
On Thu, 11 Jan 2024, Martin Storsjö wrote: On some platforms (in particular, ARM/AArch64), the implementation of AV_READ_TIME() may use a privileged instruction - in such cases, benchmarking just fails with a SIGILL. Instead of crashing, try executing AV_READ_TIME() once within a region with the signal handler active, to allow gracefully informing the user about the issue. This matches the dav1d checkasm commit 95a192549a448b70d9542e840c4e34b60d09b093. --- Reworded the commit message and the printed warning message, as the actual type of the timer is undefined and varies across platforms. --- tests/checkasm/checkasm.c | 12 +++- 1 file changed, 11 insertions(+), 1 deletion(-) Will apply soon. // Martin ___ 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: AVX512-capable laptop
On Mon, Jan 15, 2024 at 9:58 AM Kieran Kunhya wrote: > On Sun, 14 Jan 2024, 17:24 Lynne, wrote: > > > Jan 9, 2024, 19:57 by d...@lynne.ee: > > > > > Jan 3, 2024, 04:30 by d...@lynne.ee: > > > > > >> Jan 3, 2024, 04:04 by d...@lynne.ee: > > >> > > >>> Jan 3, 2024, 02:22 by jamr...@gmail.com: > > >>> > > On 1/2/2024 9:56 PM, Lynne wrote: > > > > > As some of you know, my laptop died nearly 2 years ago, and > > > I've been working on a desktop machine, which is currently a Zen 3. > > > AVX512 has become more popular in the meantime, with Zen 4 > > > and future AMD CPUs shipping with it, but currently, we have very > > > little AVX512. > > > In short, I'd like a machine which runs an AVX512-capable > > > AMD CPU, and as the world is opening up more and more, I'd > > > like for it to be portable. > > > > > > I've looked around a lot, but as Intel still has a firm monopoly, > > > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). > > > What I think I've settled for is an ASUS Vivobook Pro 15, with a > > > 7940HS CPU (the second least powerful Zen 4 mobile CPU), > > > > > > > 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure > > where you got second least powerful from. > > > > > > > https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) > > > > >>> > > >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake > > >>> (and AMD's mistake for making 4 versioning formats): > > >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors > > >>> > > >>> > > > currently trading for 1999.0 EUR on amazon.de. > > > > > > > > > https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR > > > > > > The other alternative I've found is a Lenovo Legion 7 Pro, but > > > it's more expensive at 2399 EUR (currently seems temporarily > > > discounted due to the holidays). > > > > > > > I see a Lenovo Yoga Pro 7 available for 1099 EUR. > > > https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ > > > > Same amount of RAM, screen resolution and storage, and a Ryzen 7. > > > > >>> > > >>> It's a good suggestion, but I have a better one, that's somewhat more > > expensive, > > >>> but has a better screen, better build quality, and is cheaper than > the > > Vivobook: > > >>> > > >>> A Lenovo ThinkPad P14s Gen 4 with the following options: > > >>> - Windows 14 Home (if you don't pick Windows, the OLED display is > not > > available for no reason) > > >>> - 32Gb of RAM > > >>> - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) > > >>> - 2880x1800 OLED monitor > > >>> - 4-cell battery (only 10 EUR more) > > >>> - English (EU) keyboard, without backlighting > > >>> > > >>> > > > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 > > >>> > > >> > > >> Correction: link I pasted was for the P16s, not the P14s, this is the > > correct link: > > >> > > > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 > > >> > > > > > > Ping. So far I have one approval from Michael. > > > > > > > Ping. > > > > I agree with Remi's objections to this. > > Kieran > Poor and irrelevant devs object and want to keep money for themself. > > > > ___ > 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] Hardware purchase request: AVX512-capable laptop
On Sun, 14 Jan 2024, 17:24 Lynne, wrote: > Jan 9, 2024, 19:57 by d...@lynne.ee: > > > Jan 3, 2024, 04:30 by d...@lynne.ee: > > > >> Jan 3, 2024, 04:04 by d...@lynne.ee: > >> > >>> Jan 3, 2024, 02:22 by jamr...@gmail.com: > >>> > On 1/2/2024 9:56 PM, Lynne wrote: > > > As some of you know, my laptop died nearly 2 years ago, and > > I've been working on a desktop machine, which is currently a Zen 3. > > AVX512 has become more popular in the meantime, with Zen 4 > > and future AMD CPUs shipping with it, but currently, we have very > > little AVX512. > > In short, I'd like a machine which runs an AVX512-capable > > AMD CPU, and as the world is opening up more and more, I'd > > like for it to be portable. > > > > I've looked around a lot, but as Intel still has a firm monopoly, > > the options are limited (7940H(S), 7945HX, 7845HX, 8945HS). > > What I think I've settled for is an ASUS Vivobook Pro 15, with a > > 7940HS CPU (the second least powerful Zen 4 mobile CPU), > > > > 7940HS is the highest Ryzen 9 model from the 7040 series. Not sure > where you got second least powerful from. > > > https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors#Phoenix_(7040_series,_Zen_4/RDNA3_based) > > >>> > >>> Was reading Wikipedia, and thought it was a Zen 3, my mistake > >>> (and AMD's mistake for making 4 versioning formats): > >>> https://en.wikipedia.org/wiki/List_of_AMD_Ryzen_processors > >>> > >>> > > currently trading for 1999.0 EUR on amazon.de. > > > > > https://www.amazon.de/-/en/Vivobook-Display-R9-7940HS-Windows-Keyboard/dp/B0BRYTS8MR > > > > The other alternative I've found is a Lenovo Legion 7 Pro, but > > it's more expensive at 2399 EUR (currently seems temporarily > > discounted due to the holidays). > > > > I see a Lenovo Yoga Pro 7 available for 1099 EUR. > https://www.amazon.de/-/en/Lenovo-Display-Graphics-Blue-Green-Premium/dp/B0CGLPVQHK/ > > Same amount of RAM, screen resolution and storage, and a Ryzen 7. > > >>> > >>> It's a good suggestion, but I have a better one, that's somewhat more > expensive, > >>> but has a better screen, better build quality, and is cheaper than the > Vivobook: > >>> > >>> A Lenovo ThinkPad P14s Gen 4 with the following options: > >>> - Windows 14 Home (if you don't pick Windows, the OLED display is not > available for no reason) > >>> - 32Gb of RAM > >>> - 1Tb "performance" SSD (it's 70 EUR more, but twice the size) > >>> - 2880x1800 OLED monitor > >>> - 4-cell battery (only 10 EUR more) > >>> - English (EU) keyboard, without backlighting > >>> > >>> > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K9CTO1WWDE2 > >>> > >> > >> Correction: link I pasted was for the P16s, not the P14s, this is the > correct link: > >> > https://www.lenovo.com/de/de/configurator/cto/index.html?bundleId=21K5CTO1WWDE2 > >> > > > > Ping. So far I have one approval from Michael. > > > > Ping. > I agree with Remi's objections to this. Kieran > ___ 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".
