Re: [FFmpeg-devel] [PATCH 2/2] lavc/qsvenc: add support for oneVPL string API
On Do, 2024-02-29 at 13:34 +0800, Xiang, Haihao wrote:
> From: "Mandava, Mounika"
>
> A new option -qsv_params is added, where is a :-separated
> list of key=value parameters.
>
> Example:
> $ ffmpeg -y -f lavfi -i testsrc -vf "format=nv12" -c:v h264_qsv -qsv_params
> "TargetUsage=1:GopPicSize=30:GopRefDist=2:TargetKbps=5000" -f null -
>
> Signed-off-by: Mounika Mandava
> Signed-off-by: Haihao Xiang
> ---
> Changelog | 1 +
> configure | 2 ++
> doc/encoders.texi | 14 ++
> libavcodec/qsvenc.c | 62 +
> libavcodec/qsvenc.h | 8 +-
> 5 files changed, 86 insertions(+), 1 deletion(-)
>
> diff --git a/Changelog b/Changelog
> index 610ee61dd6..b137d089d8 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -27,6 +27,7 @@ version :
> - a C11-compliant compiler is now required; note that this requirement
> will be bumped to C17 in the near future, so consider updating your
> build environment if it lacks C17 support
> +- qsv_params option added for QSV encoders
>
> version 6.1:
> - libaribcaption decoder
> diff --git a/configure b/configure
> index bb5e630bad..046c481f63 100755
> --- a/configure
> +++ b/configure
> @@ -2431,6 +2431,7 @@ TYPES_LIST="
> struct_sockaddr_storage
> struct_stat_st_mtim_tv_nsec
> struct_v4l2_frmivalenum_discrete
> + struct_mfxConfigInterface
> "
>
> HAVE_LIST="
> @@ -6828,6 +6829,7 @@ elif enabled libvpl; then
> check_pkg_config libmfx "vpl >= 2.6" "mfxvideo.h mfxdispatcher.h" MFXLoad
> || \
> die "ERROR: libvpl >= 2.6 not found"
> add_cflags -DMFX_DEPRECATED_OFF
> + check_type "vpl/mfxdefs.h vpl/mfxvideo.h" "struct mfxConfigInterface"
> fi
>
> if enabled libmfx; then
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 9f477d7c53..cbd3b538cf 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3485,6 +3485,20 @@ Change these value to reset qsv codec's bitrate control
> configuration.
> @item @var{pic_timing_sei}
> Supported in h264_qsv and hevc_qsv.
> Change this value to reset qsv codec's pic_timing_sei configuration.
> +
> +@item @var{qsv_params}
> +Set QSV encoder parameters as a colon-separated list of key-value pairs.
> +
> +The @option{qsv_params} should be formatted as
> @code{key1=value1:key2=value2:...}.
> +
> +These parameters are passed directly to the underlying Intel Quick Sync Video
> (QSV) encoder using the MFXSetParameter function.
> +
> +Example:
> +@example
> +ffmpeg -i input.mp4 -c:v h264_qsv -qsv_params
> "CodingOption1=1:CodingOption2=2" output.mp4
> +@end example
> +
> +This option allows fine-grained control over various encoder-specific
> settings provided by the QSV encoder.
> @end table
>
> @subsection H264 options
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 27e0e7ee71..0189c219d2 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -31,6 +31,7 @@
> #include "libavutil/hwcontext_qsv.h"
> #include "libavutil/mem.h"
> #include "libavutil/log.h"
> +#include "libavutil/dict.h"
> #include "libavutil/time.h"
> #include "libavutil/imgutils.h"
>
> @@ -1609,6 +1610,11 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
> QSVEncContext *q)
> int opaque_alloc = 0;
> int ret;
> void *tmp;
> +#if HAVE_STRUCT_MFXCONFIGINTERFACE
> + mfxExtBuffer ext_buf;
> + mfxConfigInterface *iface = NULL;
> + const AVDictionaryEntry *param = NULL;
> +#endif
>
> q->param.AsyncDepth = q->async_depth;
>
> @@ -1703,6 +1709,58 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
> QSVEncContext *q)
> q->param.ExtParam = q->extparam;
> q->param.NumExtParam = q->nb_extparam;
>
> +#if HAVE_STRUCT_MFXCONFIGINTERFACE
> + ret = MFXVideoCORE_GetHandle(q->session, MFX_HANDLE_CONFIG_INTERFACE,
> (mfxHDL *)());
> + if (ret < 0)
> + return ff_qsv_print_error(avctx, ret,
> + "Error getting mfx config interface
> handle");
> +
> + while ((param = av_dict_get(q->qsv_params, "", param,
> AV_DICT_IGNORE_SUFFIX))) {
> + const char *param_key = param->key;
> + const char *param_value = param->value;
> + mfxExtBuffer *new_ext_buf;
> + void *tmp;
> +
> + av_log(avctx, AV_LOG_VERBOSE, "Parameter key: %s, value: %s\n",
> param_key, param_value);
> +
> + // Set encoding parameters using MFXSetParameter
> + for (int i = 0; i < 2; i++) {
> + ret = iface->SetParameter(iface, (mfxU8*)param_key,
> (mfxU8*)param_value, MFX_STRUCTURE_TYPE_VIDEO_PARAM, >param, _buf);
> + if (ret == MFX_ERR_NONE) {
> + break;
> + } else if (i == 0 && ret == MFX_ERR_MORE_EXTBUFFER) {
> + tmp = av_realloc_array(q->extparam_str, q->nb_extparam_str +
> 1, sizeof(*q->extparam_str));
> + if (!tmp)
> + return AVERROR(ENOMEM);
> + q->extparam_str = tmp;
> +
> + tmp =
Re: [FFmpeg-devel] [PATCH 1/9] lavu/hwcontext_qsv: update AVQSVFramesContext to support dynamic frame pool
On Do, 2024-05-02 at 20:35 +0100, Mark Thompson wrote:
> On 28/04/2024 08:39, Xiang, Haihao wrote:
> > From: Haihao Xiang
> >
> > Add AVQSVFramesContext.info and update the description.
> >
> > Signed-off-by: Haihao Xiang
> > ---
> > doc/APIchanges | 3 +++
> > libavutil/hwcontext_qsv.c | 4 ++--
> > libavutil/hwcontext_qsv.h | 28 +---
> > libavutil/version.h | 4 ++--
> > 4 files changed, 32 insertions(+), 7 deletions(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 0566fcdcc5..4a434b2877 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-
> > 07
> >
> > API changes, most recent first:
> >
> > +2024-04-xx - xx - lavu 59.17.100 - hwcontext_qsv.h
> > + Add AVQSVFramesContext.info
> > +
> > 2024-04-24 - 8616cfe0890 - lavu 59.16.100 - opt.h
> > Add AV_OPT_SERIALIZE_SEARCH_CHILDREN.
> >
> > diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> > index c7c7878644..f552811346 100644
> > --- a/libavutil/hwcontext_qsv.c
> > +++ b/libavutil/hwcontext_qsv.c
> > @@ -627,7 +627,7 @@ static mfxStatus frame_alloc(mfxHDL pthis,
> > mfxFrameAllocRequest *req,
> > QSVFramesContext *s = ctx->hwctx;
> > AVQSVFramesContext *hwctx = >p;
> > mfxFrameInfo *i = >Info;
> > - mfxFrameInfo *i1 = >surfaces[0].Info;
> > + mfxFrameInfo *i1 = hwctx->nb_surfaces ? >surfaces[0].Info :
> > hwctx->info;
> >
> > if (!(req->Type & MFX_MEMTYPE_VIDEO_MEMORY_PROCESSOR_TARGET) ||
> > !(req->Type & (MFX_MEMTYPE_FROM_VPPIN | MFX_MEMTYPE_FROM_VPPOUT))
> > ||
> > @@ -1207,7 +1207,7 @@ static int qsv_init_internal_session(AVHWFramesContext
> > *ctx,
> > MFX_IOPATTERN_OUT_SYSTEM_MEMORY;
> > par.AsyncDepth = 1;
> >
> > - par.vpp.In = frames_hwctx->surfaces[0].Info;
> > + par.vpp.In = frames_hwctx->nb_surfaces ? frames_hwctx->surfaces[0].Info
> > : *frames_hwctx->info;
> >
> > /* Apparently VPP requires the frame rate to be set to some value,
> > otherwise
> > * init will fail (probably for the framerate conversion filter). Since
> > we
> > diff --git a/libavutil/hwcontext_qsv.h b/libavutil/hwcontext_qsv.h
> > index e2dba8ad83..9e43a237d4 100644
> > --- a/libavutil/hwcontext_qsv.h
> > +++ b/libavutil/hwcontext_qsv.h
> > @@ -25,8 +25,8 @@
> > * @file
> > * An API-specific header for AV_HWDEVICE_TYPE_QSV.
> > *
> > - * This API does not support dynamic frame pools. AVHWFramesContext.pool
> > must
> > - * contain AVBufferRefs whose data pointer points to an mfxFrameSurface1
> > struct.
> > + * AVHWFramesContext.pool must contain AVBufferRefs whose data pointer
> > points
> > + * to a mfxFrameSurface1 struct.
> > */
> >
> > /**
> > @@ -51,7 +51,29 @@ typedef struct AVQSVDeviceContext {
> > * This struct is allocated as AVHWFramesContext.hwctx
> > */
> > typedef struct AVQSVFramesContext {
> > - mfxFrameSurface1 *surfaces;
> > + /**
> > + * A pointer to a mfxFrameSurface1 or mfxFrameInfo struct
> > + *
> > + * When nb_surfaces is non-zero, it is a pointer to a mfxFrameSurface1
> > + * struct.
> > + *
> > + * When nb_surfaces is 0, it is a pointer to a mfxFrameInfo struct, all
> > + * buffers allocated from the pool have the same mfxFrameInfo.
> > + */
> > + union {
> > + mfxFrameSurface1 *surfaces;
> > + mfxFrameInfo *info;
> > + };
>
> doc/developer.texi:
>
> "FFmpeg is mainly programmed in the ISO C11 language, except for the public
> headers which must stay C99 compatible."
>
> Anonymous unions are therefore not allowed in public headers.
Thanks for pointing it out, I missed this statement.
>
> Can you explain what you need the info field for, though? (What is needed but
> can't be inferred elsewhere? VAAPI in particular is can be mapped here but
> doesn't contain any special information like this.)
The info is used in libavcodec and libavfilter. My thought is we may get the
info from surfaces directly for fixed frame pool in libavcodec and libavfilter,
It is better to have a field too for the info in dynamic frame pool so we
needn't infer the info in libavcodec and libavfilter.
Thanks
Haihao
>
> > +
> > + /**
> > + * Number of frames in the pool
> > + *
> > + * It is 0 for dynamic frame pools or
> > AVHWFramesContext.initial_pool_size
> > + * for fixed frame pools.
> > + *
> > + * Note only oneVPL GPU runtime 2.9+ can support dynamic frame pools
> > + * on d3d11va or vaapi
> > + */
> > int nb_surfaces;
>
> +1 to adding proper documentation for these fields.
>
> >
> > /**
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index 735f6832e3..3b5a2e7aaa 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -79,8 +79,8 @@
> > */
> >
> > #define LIBAVUTIL_VERSION_MAJOR 59
> > -#define
[FFmpeg-devel] Samples with invalid permissions
Hi, There are a couple of files in samples.ffmpeg.org with invalid permissions, rsync is not able to read those: /V-codecs/UCOD/noextradata/CLV1_tony.mov /V-codecs/UCOD/noextradata/freddie2.mov /V-codecs/UCOD/noextradata/pittc.mov /V-codecs/UCOD/noextradata/smilla_cv.mov /ffmpeg-bugs/trac/ticket4729/hap2_fuzz.mov /ffmpeg-bugs/trac/ticket5406/crushed_1.snm /ffmpeg-bugs/trac/ticket5407/512kbps.wv /ffmpeg-bugs/trac/ticket5407/512kbps.wvc /ffmpeg-bugs/trac/ticket5410/ela2.m4b /ffmpeg-bugs/trac/ticket5410/intro_a.m4b /ffmpeg-bugs/trac/ticket5925/non-work-spanned.zip /ffmpeg-bugs/trac/ticket6102/error_reading_header_ticket_6102_first100.mp4 /ffmpeg-bugs/trac/ticket6102/error_reading_header_ticket_6102_last100.mp4 /ffmpeg-bugs/trac/ticket6400/tooshort.avi /ffmpeg-bugs/trac/ticket6675/Cineform_Bottom_8_Pixel_Distort_1080_YUV.mov /ffmpeg-bugs/trac/ticket6765/Canon-C200-Raw.CRM Can someone with access please check? Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: only check index_edit_rate when calculating the index tables
On Fri, 3 May 2024, Tomas Härdin wrote: tor 2024-05-02 klockan 23:01 +0200 skrev Marton Balint: On Mon, 29 Apr 2024, Tomas Härdin wrote: > mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint: > > Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting > > negative > > index segment edit rates to avoid negative av_rescale parameters. > > There are two > > problems with this: > > > > 1) there is already a validation for zero (uninitialized) rates > > later > > on > > 2) it rejects files with 0/0 index edit rates which do exist and > > we > > should > > continue to support those > > There are no such files in FATE last time I checked. At the very > least > we need to know which vendor is producing such broken files. > > Without tests covering the workflows we want to support, we have no > confidence in refactoriing. This leads to cargo culting. And to be > sure, every workflow we support means a non-trivial amount of work, > especially when it comes to MXF. I can add a comment to the code or the commit message, we did this plenty of times in the past. The broken software is Marquise Technologies MT Mediabase 4.7.2 by the way. I can also rework the patch to keep rejecting negative values and only allow zero, as that is the only thing I *know* to exist. We could also tell Marquise Technologies to fix their software. MXF is a living ecosystem If we add a new FATE file for every fixed file or workflow, the amount of FATE samples (and the time fate will run) will increase significantly, I am not sure that is intended. "Support any old workflow but don't add tests for them" is a ridiculous position. It also prevents refactoring. There are real costs to supporting workflows that no one uses. Hence why I mention SLAs. The only people interested in MXF are professionals. And what if a home user gets a file from a professional user? Crippling professional use cases from ffmpeg, or make professional features a payable option - via SLA or otherwise - is something I cannot support. In this case, I could only craft an MXF file, because I don't have access to the software. Yes we can craft arbitrarily broken files. That doesn't help anyone. It's just cargo culting. Cargo culting would be fixing files which do not exists in the wild. Files with 0/0 index edit rate do exist. So this patch clearly helps anybody who is trying to play those. I can create a fate test for supporting 0/0 index edit rates if that is indeed preferred. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
I saw about comparing emails and gitlab/hub .., I did not comprehensively understand their advantages and disadvantages, but I want to say that I support it to change to gitlab/hub Simple reason: If you need to use git-send-email, I may not be able to submit any code If you do not need to use git-send-email, it is troublesome for the reviewer and the contributor In detail: I have tried git-send-email, but it failed. You can say that I am stupid, but I would say that this is because of various reasons such as my area and the network. It is really not what I can solve. Maybe I will spend a lot of energy trying it in the future, but this is because I have submitted thousands of lines of code. I don't want to give up. If it is from the beginning, it will cause abandonment. Maybe I am younger here in FFMPEG. I have a lot of good young people around me. They all use github/lab by default, and there will be the same problem as me, resulting in abandonment. I don't really care about the quality between these tools. I think people are important. I only want to use it, and I can facilitate the real reviewer of Review. I don't know if I can say my personal feelings here, but I will say: I feel despised by this passage, which makes me uncomfortable. If you are a reviewer, maybe I have no chance to contribute, but anyway, I have made some contributions. > How can anyne use git, but not git send-email? Any develop email provider HAS Support for External Clients Over SMTP. And I Believe You * Can * Actually Dictate that people doon't attach patches - if you have control over the Mailing list software, you can set up a filter that rejects such emails And auto-replies with instructions on how to send them properly. I think I should have the right to contribute Ondřej Fiala 于2024年5月2日周四 22:25写道： > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote: > > Le 30 avril 2024 22:15:10 GMT+03:00, "Ondřej Fiala" > a écrit : > > >On Tue Apr 30, 2024 at 9:06 PM CEST, Hendrik Leppkes wrote: > > >> I will take the replacement instead, thanks. Email is archaic. The > > >> entire point is to get away from email, not dress it up. > > >> SourceHut usage would likely make me even less interested then today. > > >> > > >> - Hendrik > > >I guess that depends on how (and with what) you use it. Using it with > > >Gmail UI for example is obviously not a great idea. No idea whether you > > >do, but if you do, you should be upset at Gmail, not email. > > > > I don't use Gmail, and using email for review still sucks. No matter how > you > > slice it, email was not meant for threaded code reviews. > Email was not meant for a lot of what it's used for today. Many email > clients > have support for threading, and unlike GitHub allow threads of arbitrary > depth. Using such a client with commands for moving between messages in a > a thread etc. makes threaded code review over email quite usably in my > opinion. > > > Also while I can use git-send-email, not everyone can. And patches as > > attachments are simply awful. Unfortunately I can't dictate that people > don't > > send patches that way. > How can anyone use git, but not git send-email? Any decent email provider > has support for external clients over SMTP. And I believe you *can* > actually > dictate that people don't attach patches -- if you have control over the > mailing list software, you can set up a filter that rejects such emails > and auto-replies with instructions on how to send them properly. > > > >But you did not answer my question: which specific code review features > > >are you missing? > > > > Proper threaded reviews with state tracking, ability to collapse and > expand > > context and files, and proper listing of open MR (*not* like patchwork). > I can sort of understand everything except the last one. What is "a proper > listing of open MR" supposed to mean...? (I know what a merge request is, > of course, but I don't get how the way GitLab lists them is supposedly > superior to SourceHut's list of patches.) > ___ > 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 v1] scale: Bring back the old yuv2yuvX, use it when disable-x86asm.
On Fri, May 03, 2024 at 04:07:36AM +0800, hu heng wrote:
> 于2024年4月26日周五 20:21写道：
> >
> > From: huheng
> >
> > rename old inline yuv2yuvX to yuv2yuv_X, to avoid conflicts with
> > the names of standalone asm functions. When ffmpeg is compiled with
> > --disable-x86asm, using the scale function will cause the video to
> > be blurred. The reason is that when disable-x86asm, INLINE_MMXEXT
> > is 1 and use_mmx_vfilter is 1, but c->yuv2planeX uses the c language
> > version, which causes a problem of mismatch with the vfilter. This
> > problem has persisted from version 4.4 to the present. Fix it by using
> > inline yuv2yuv_X_mmxext, that can maintain the consistency of
> > use_mmx_vfilter.
> >
> > reproduce the issue:
> > 1. ./configure --disable-x86asm --enable-gpl --enable-libx264
> > 2. ./ffmpeg -i input.mp4 -vf "scale=1280x720" -c:v libx264 output.mp4
> > the output.mp4 is abnormal
> >
> > Signed-off-by: huheng
> > ---
> > libswscale/x86/swscale.c | 6 +++-
> > libswscale/x86/swscale_template.c | 53 +++
> > 2 files changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
> > index ff16398988..1bb9d1d51a 100644
> > --- a/libswscale/x86/swscale.c
> > +++ b/libswscale/x86/swscale.c
> > @@ -452,8 +452,12 @@ av_cold void ff_sws_init_swscale_x86(SwsContext *c)
> > int cpu_flags = av_get_cpu_flags();
> >
> > #if HAVE_MMXEXT_INLINE
> > -if (INLINE_MMXEXT(cpu_flags))
> > +if (INLINE_MMXEXT(cpu_flags)) {
> > sws_init_swscale_mmxext(c);
> > +if (c->use_mmx_vfilter && !(c->flags & SWS_ACCURATE_RND)) {
> > +c->yuv2planeX = yuv2yuv_X_mmxext;
> > +}
> > +}
> > #endif
> > if(c->use_mmx_vfilter && !(c->flags & SWS_ACCURATE_RND)) {
> > #if HAVE_MMXEXT_EXTERNAL
> > diff --git a/libswscale/x86/swscale_template.c
> > b/libswscale/x86/swscale_template.c
> > index 6190fcb4fe..1b8794480d 100644
> > --- a/libswscale/x86/swscale_template.c
> > +++ b/libswscale/x86/swscale_template.c
> > @@ -33,6 +33,59 @@
> > #define MOVNTQ2 "movntq "
> > #define MOVNTQ(a,b) REAL_MOVNTQ(a,b)
> >
> > +static void RENAME(yuv2yuv_X)(const int16_t *filter, int filterSize,
> > + const int16_t **src, uint8_t *dest, int dstW,
> > + const uint8_t *dither, int offset)
> > +{
> > +filterSize--;
> > +__asm__ volatile(
> > +"movd %0, %%mm1\n\t"
> > +"punpcklwd %%mm1, %%mm1\n\t"
> > +"punpckldq %%mm1, %%mm1\n\t"
> > +"psllw$3, %%mm1\n\t"
> > +"paddw %%mm1, %%mm3\n\t"
> > +"paddw %%mm1, %%mm4\n\t"
> > +"psraw$4, %%mm3\n\t"
> > +"psraw$4, %%mm4\n\t"
> > +::"m"(filterSize)
> > + );
> > +
> > +__asm__ volatile(\
> > +"movq%%mm3, %%mm6\n\t"
> > +"movq%%mm4, %%mm7\n\t"
> > +"movl %3, %%ecx\n\t"
> > +"mov %0, %%"FF_REG_d" \n\t"\
> > +"mov(%%"FF_REG_d"), %%"FF_REG_S"\n\t"\
> > +".p2align 4 \n\t"
> > /* FIXME Unroll? */\
> > +"1: \n\t"\
> > +"movq 8(%%"FF_REG_d"), %%mm0 \n\t"
> > /* filterCoeff */\
> > +"movq(%%"FF_REG_S", %%"FF_REG_c", 2), %%mm2 \n\t"
> > /* srcData */\
> > +"movq 8(%%"FF_REG_S", %%"FF_REG_c", 2), %%mm5 \n\t"
> > /* srcData */\
> > +"add$16, %%"FF_REG_d" \n\t"\
> > +"mov(%%"FF_REG_d"), %%"FF_REG_S"\n\t"\
> > +"test %%"FF_REG_S", %%"FF_REG_S"\n\t"\
> > +"pmulhw %%mm0, %%mm2 \n\t"\
> > +"pmulhw %%mm0, %%mm5 \n\t"\
> > +"paddw%%mm2, %%mm3 \n\t"\
> > +"paddw%%mm5, %%mm4 \n\t"\
> > +" jnz1b \n\t"\
> > +"psraw $3, %%mm3 \n\t"\
> > +"psraw $3, %%mm4 \n\t"\
> > +"packuswb %%mm4, %%mm3 \n\t"
> > +MOVNTQ2 " %%mm3, (%1, %%"FF_REG_c")\n\t"
> > +"add $8, %%"FF_REG_c" \n\t"\
> > +"cmp %2, %%"FF_REG_c" \n\t"\
> > +"movq%%mm6, %%mm3\n\t"
> > +"movq%%mm7, %%mm4\n\t"
> > +"mov %0, %%"FF_REG_d" \n\t"\
> > +"mov(%%"FF_REG_d"), %%"FF_REG_S" \n\t"\
> > +"jb 1b \n\t"\
> > +:: "g" (filter),
> > + "r"
Re: [FFmpeg-devel] [PATCH 4/5] avcodec/dovi_rpuenc: Initialize bl_compat_id
On Sat, May 04, 2024 at 12:21:03AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > Fixes: CID1596607 Uninitialized scalar variable > > > > Sponsored-by: Sovereign Tech Fund > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/dovi_rpuenc.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c > > index 7e0292533bd..c5e452957b5 100644 > > --- a/libavcodec/dovi_rpuenc.c > > +++ b/libavcodec/dovi_rpuenc.c > > @@ -57,7 +57,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext > > *avctx) > > AVDOVIDecoderConfigurationRecord *cfg; > > const AVDOVIRpuDataHeader *hdr = NULL; > > const AVFrameSideData *sd; > > -int dv_profile, dv_level, bl_compat_id; > > +int dv_profile, dv_level, bl_compat_id = -1; > > size_t cfg_size; > > uint64_t pps; > > > > This is unnecessary, as the dv_profile switch is exhaustive (i.e. the > default case is never taken); but if you do this, then you can also > remove the other "bl_compat_id = -1" assignments (which conveys that > everything is treated as invalid unless we found it to have a valid > compatibility id). i see case AV_CODEC_ID_H264: dv_profile = 9; break; the dv_profile switch only contains 0 4 7 5 10 8 no 9 what am i missing ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire 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 1/2] avformat/movenc: Check av_malloc()
On Thu, May 02, 2024 at 11:34:15PM +0200, Andreas Rheinhardt wrote: > Fixes Coverity issue #1596735. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/movenc.c | 2 ++ > 1 file changed, 2 insertions(+) LGTM 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] [PATCH] fftools/ffprobe: Avoid overflow when calculating DAR
On Fri, May 03, 2024 at 05:36:23PM +0100, Derek Buitenhuis wrote: > Both the codecpar's width and height, and the SAR num and den are > ints, which can overflow. Cast to int64_t, which is what av_reduce > takes. > > Without this, occasionally, display_aspect_ratio can be negative in > ffprobe's -show_stream output. > > Signed-off-by: Derek Buitenhuis > --- > fftools/ffprobe.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin 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 4/5] avcodec/dovi_rpuenc: Initialize bl_compat_id
Michael Niedermayer: > Fixes: CID1596607 Uninitialized scalar variable > > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > --- > libavcodec/dovi_rpuenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c > index 7e0292533bd..c5e452957b5 100644 > --- a/libavcodec/dovi_rpuenc.c > +++ b/libavcodec/dovi_rpuenc.c > @@ -57,7 +57,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx) > AVDOVIDecoderConfigurationRecord *cfg; > const AVDOVIRpuDataHeader *hdr = NULL; > const AVFrameSideData *sd; > -int dv_profile, dv_level, bl_compat_id; > +int dv_profile, dv_level, bl_compat_id = -1; > size_t cfg_size; > uint64_t pps; > This is unnecessary, as the dv_profile switch is exhaustive (i.e. the default case is never taken); but if you do this, then you can also remove the other "bl_compat_id = -1" assignments (which conveys that everything is treated as invalid unless we found it to have a valid compatibility id). - 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".
[FFmpeg-devel] [PATCH 5/5] avcodec/exr: Fix preview overflow
Fixes: CID1515456 Unintentional integer overflow
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/exr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 8bd39f78a45..4bac0be89b2 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1943,7 +1943,7 @@ static int decode_header(EXRContext *s, AVFrame *frame)
"preview", 16)) >= 0) {
uint32_t pw = bytestream2_get_le32(gb);
uint32_t ph = bytestream2_get_le32(gb);
-uint64_t psize = pw * ph;
+uint64_t psize = pw * (uint64_t)ph;
if (psize > INT64_MAX / 4) {
ret = AVERROR_INVALIDDATA;
goto fail;
--
2.43.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".
[FFmpeg-devel] [PATCH 4/5] avcodec/dovi_rpuenc: Initialize bl_compat_id
Fixes: CID1596607 Uninitialized scalar variable Sponsored-by: Sovereign Tech Fund Signed-off-by: Michael Niedermayer --- libavcodec/dovi_rpuenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c index 7e0292533bd..c5e452957b5 100644 --- a/libavcodec/dovi_rpuenc.c +++ b/libavcodec/dovi_rpuenc.c @@ -57,7 +57,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx) AVDOVIDecoderConfigurationRecord *cfg; const AVDOVIRpuDataHeader *hdr = NULL; const AVFrameSideData *sd; -int dv_profile, dv_level, bl_compat_id; +int dv_profile, dv_level, bl_compat_id = -1; size_t cfg_size; uint64_t pps; -- 2.43.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".
[FFmpeg-devel] [PATCH 3/5] avcodec/dovi_rpuenc: fix compaatibility
Fixes: a frequency
Found while reviewing: CID1596607
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dovi_rpuenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 80dc22234a9..7e0292533bd 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -139,7 +139,7 @@ int ff_dovi_configure(DOVIContext *s, AVCodecContext *avctx)
if (!dv_profile || bl_compat_id < 0) {
if (s->enable > 0) {
av_log(s->logctx, AV_LOG_ERROR, "Dolby Vision enabled, but could "
- "not determine profile and compaatibility mode.
Double-check "
+ "not determine profile and compatibility mode. Double-check
"
"colorspace and format settings for compatibility?\n");
return AVERROR(EINVAL);
}
--
2.43.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".
[FFmpeg-devel] [PATCH 2/5] avcodec/dovi_rpuenc: initialize profile
Code is taken from dovi_rpudec
Fixes: CID1596604 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/dovi_rpuenc.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/dovi_rpuenc.c b/libavcodec/dovi_rpuenc.c
index 3feaa04b9ed..80dc22234a9 100644
--- a/libavcodec/dovi_rpuenc.c
+++ b/libavcodec/dovi_rpuenc.c
@@ -571,6 +571,8 @@ int ff_dovi_rpu_generate(DOVIContext *s, const
AVDOVIMetadata *metadata,
set_ue_golomb(pb, vdr_rpu_id);
s->mapping = >vdr[vdr_rpu_id]->mapping;
+profile = s->cfg.dv_profile ? s->cfg.dv_profile :
ff_dovi_guess_profile_hevc(hdr);
+
if (!use_prev_vdr_rpu) {
set_ue_golomb(pb, mapping->mapping_color_space);
set_ue_golomb(pb, mapping->mapping_chroma_format_idc);
--
2.43.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".
[FFmpeg-devel] [PATCH 1/5] avcodec/decode: decode_simple_internal() only implements audio and video
Fixes: CID1538861 Uninitialized scalar variable
Sponsored-by: Sovereign Tech Fund
Signed-off-by: Michael Niedermayer
---
libavcodec/decode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index d031b1ca176..900b0c07a35 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -431,7 +431,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
} else if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
ret = !got_frame ? AVERROR(EAGAIN)
: discard_samples(avctx, frame, discarded_samples);
-}
+} else
+av_assert0(0);
if (ret == AVERROR(EAGAIN))
av_frame_unref(frame);
--
2.43.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".
[FFmpeg-devel] [PATCH] avfilter/vf_scale: add missing filter flag
From: Niklas Haas
Fixes: bb8044581366fe286e16b14515d873979133dbda
---
libavfilter/vf_scale.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
index bc53571c1c..696ee272ec 100644
--- a/libavfilter/vf_scale.c
+++ b/libavfilter/vf_scale.c
@@ -1261,6 +1261,7 @@ const AVFilter ff_vf_scale = {
FILTER_QUERY_FUNC(query_formats),
.activate= activate,
.process_command = process_command,
+.flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
};
static const AVFilterPad avfilter_vf_scale2ref_inputs[] = {
--
2.44.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] lavc/ac3dsp: R-V Zbb ac3_exponent_min
SiFive U74: ac3_exponent_min_reuse0_c: 10.0 ac3_exponent_min_reuse0_rvb_b:8.0 ac3_exponent_min_reuse1_c: 2924.7 ac3_exponent_min_reuse1_rvb_b: 1803.0 ac3_exponent_min_reuse2_c: 5043.0 ac3_exponent_min_reuse2_rvb_b: 2827.5 ac3_exponent_min_reuse3_c: 7028.7 ac3_exponent_min_reuse3_rvb_b: 3872.0 ac3_exponent_min_reuse4_c: 8824.2 ac3_exponent_min_reuse4_rvb_b: 5122.2 ac3_exponent_min_reuse5_c:10487.5 ac3_exponent_min_reuse5_rvb_b: 6412.2 --- libavcodec/riscv/ac3dsp_init.c | 3 +++ libavcodec/riscv/ac3dsp_rvb.S | 21 + 2 files changed, 24 insertions(+) diff --git a/libavcodec/riscv/ac3dsp_init.c b/libavcodec/riscv/ac3dsp_init.c index c7c375273d..8cfa69055a 100644 --- a/libavcodec/riscv/ac3dsp_init.c +++ b/libavcodec/riscv/ac3dsp_init.c @@ -26,6 +26,7 @@ #include "libavutil/cpu.h" #include "libavcodec/ac3dsp.h" +void ff_ac3_exponent_min_rvb(uint8_t *exp, int, int); void ff_ac3_exponent_min_rvv(uint8_t *exp, int, int); void ff_extract_exponents_rvb(uint8_t *exp, int32_t *coef, int nb_coefs); void ff_float_to_fixed24_rvv(int32_t *dst, const float *src, size_t len); @@ -39,6 +40,8 @@ av_cold void ff_ac3dsp_init_riscv(AC3DSPContext *c) #if HAVE_RV int flags = av_get_cpu_flags(); +if (flags & AV_CPU_FLAG_RVB_BASIC) +c->ac3_exponent_min = ff_ac3_exponent_min_rvb; if (flags & AV_CPU_FLAG_RVV_I32) c->ac3_exponent_min = ff_ac3_exponent_min_rvv; diff --git a/libavcodec/riscv/ac3dsp_rvb.S b/libavcodec/riscv/ac3dsp_rvb.S index 48f8bb101e..0ca56466e1 100644 --- a/libavcodec/riscv/ac3dsp_rvb.S +++ b/libavcodec/riscv/ac3dsp_rvb.S @@ -21,6 +21,27 @@ #include "config.h" #include "libavutil/riscv/asm.S" +func ff_ac3_exponent_min_rvb, zbb +beqza1, 3f +1: +addia2, a2, -1 +lb t3, (a0) +addit0, a0, 256 +mv t1, a1 +2: +lb t4, (t0) +addit1, t1, -1 +addit0, t0, 256 +minut3, t3, t4 +bnezt1, 2b + +sb t3, (a0) +addia0, a0, 1 +bneza2, 1b +3: +ret +endfunc + func ff_extract_exponents_rvb, zbb 1: lw t0, (a1) -- 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] [RFC] 5 year plan & Inovation
Le perjantaina 3. toukokuuta 2024, 20.30.16 EEST Ondřej Fiala a écrit : > > You can't expect the whole community to accomodate your unwillingness to > > run a web browser or update a ridiculous underprovisioned computer > > system. > There is a huge difference between running a web browser and running > Firefox/Chrome that you're consistently ignoring. I absolutely don't > mind running Lynx... :) My point is that the requirement for *practical* *use* of an HTML5 web browser are lower than those for compiling, and running the test suite of, FFmpeg. Sure you can run Links, W3M or NCSA Mosaic with a lot lower requirements, and Gitlab probably does not work under any of those. But the point is that Chromium or Firefox are *not* really limitting factors here. -- レミ・デニ-クールモン 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] [RFC] 5 year plan & Inovation
On Fri May 3, 2024 at 4:41 PM CEST, Rémi Denis-Courmont wrote: > Le perjantaina 3. toukokuuta 2024, 15.58.50 EEST Ondřej Fiala a écrit : > > > And in the end, I could be wrong, but I haven't seen you doing much code > > > review here. This is all about optimising the workflow for people doing > > > code reviews and code merges, so why do you even care? > > > > Because your "optimizations" will make contributing to ffmpeg significantly > > harder for people like me. > > All they do is make the first contribution harder because you have to create > an > account on, and clone the repository within, the web forge. Considering the > distribution between first-time contributions versus reviews and further-time > contributions, that is a very obviously worthy tradeoff. > > Note that I don't particularly prefer Gitlab vs email for submitting code. > They both have their pros and cons, and I do not really like either of them. > But Gitlab is so much easier for code review and merge, and it looks to me > that the shortage of reviewers is even more pressing than developers here. Fair enough. > You can't expect the whole community to accomodate your unwillingness to run > a > web browser or update a ridiculous underprovisioned computer system. There is a huge difference between running a web browser and running Firefox/Chrome that you're consistently ignoring. I absolutely don't mind running Lynx... :) ___ 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] lavu/riscv: indent code
This reindents code to prepare for the next changeset.
No functional changes.
---
libavutil/riscv/cpu.c | 28 +++-
1 file changed, 15 insertions(+), 13 deletions(-)
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 460d3e9f91..984293aef0 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -32,21 +32,23 @@ int ff_get_cpu_flags_riscv(void)
{
int ret = 0;
#if HAVE_GETAUXVAL
-const unsigned long hwcap = getauxval(AT_HWCAP);
+{
+const unsigned long hwcap = getauxval(AT_HWCAP);
-if (hwcap & HWCAP_RV('I'))
-ret |= AV_CPU_FLAG_RVI;
-if (hwcap & HWCAP_RV('F'))
-ret |= AV_CPU_FLAG_RVF;
-if (hwcap & HWCAP_RV('D'))
-ret |= AV_CPU_FLAG_RVD;
-if (hwcap & HWCAP_RV('B'))
-ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC;
+if (hwcap & HWCAP_RV('I'))
+ret |= AV_CPU_FLAG_RVI;
+if (hwcap & HWCAP_RV('F'))
+ret |= AV_CPU_FLAG_RVF;
+if (hwcap & HWCAP_RV('D'))
+ret |= AV_CPU_FLAG_RVD;
+if (hwcap & HWCAP_RV('B'))
+ret |= AV_CPU_FLAG_RVB_ADDR | AV_CPU_FLAG_RVB_BASIC;
-/* The V extension implies all Zve* functional subsets */
-if (hwcap & HWCAP_RV('V'))
-ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
- | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+/* The V extension implies all Zve* functional subsets */
+if (hwcap & HWCAP_RV('V'))
+ ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
+ | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+}
#endif
#ifdef __riscv_i
--
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 2/2] lavu/riscv: add hwprobe() for CPU detection
This adds the Linux-specific function call to detect CPU features. Unlike
the more portable auxillary vector, this supports extensions other than
single lettered ones. At this point, FFmpeg already needs this to detect
Zba and Zbb at run-time, and probably will need it for Zvbb in the near
future.
Support will be available in glibc 2.40 onward.
---
configure | 3 +++
libavutil/riscv/cpu.c | 25 +
2 files changed, 28 insertions(+)
diff --git a/configure b/configure
index ed74583a6f..bc8f40ed85 100755
--- a/configure
+++ b/configure
@@ -2298,6 +2298,7 @@ HEADERS_LIST="
OpenGL_gl3_h
poll_h
pthread_np_h
+sys_hwprobe_h
sys_param_h
sys_resource_h
sys_select_h
@@ -5537,6 +5538,8 @@ elif enabled ppc; then
elif enabled riscv; then
+check_headers sys/hwprobe.h
+
if test_cpp_condition stddef.h "__riscv_zbb"; then
enable fast_clz
fi
diff --git a/libavutil/riscv/cpu.c b/libavutil/riscv/cpu.c
index 984293aef0..c3683b06d0 100644
--- a/libavutil/riscv/cpu.c
+++ b/libavutil/riscv/cpu.c
@@ -18,8 +18,10 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#define _GNU_SOURCE
#include "libavutil/cpu.h"
#include "libavutil/cpu_internal.h"
+#include "libavutil/macros.h"
#include "libavutil/log.h"
#include "config.h"
@@ -27,10 +29,33 @@
#include
#define HWCAP_RV(letter) (1ul << ((letter) - 'A'))
#endif
+#ifdef HAVE_SYS_HWPROBE_H
+#include
+#endif
int ff_get_cpu_flags_riscv(void)
{
int ret = 0;
+#ifdef HAVE_SYS_HWPROBE_H
+struct riscv_hwprobe pairs[] = {
+{ RISCV_HWPROBE_KEY_BASE_BEHAVIOR, 0 },
+{ RISCV_HWPROBE_KEY_IMA_EXT_0, 0 },
+};
+
+if (__riscv_hwprobe(pairs, FF_ARRAY_ELEMS(pairs), 0, NULL, 0) == 0) {
+if (pairs[0].value & RISCV_HWPROBE_BASE_BEHAVIOR_IMA)
+ret |= AV_CPU_FLAG_RVI;
+if (pairs[1].value & RISCV_HWPROBE_IMA_FD)
+ret |= AV_CPU_FLAG_RVF | AV_CPU_FLAG_RVD;
+if (pairs[1].value & RISCV_HWPROBE_IMA_V)
+ret |= AV_CPU_FLAG_RVV_I32 | AV_CPU_FLAG_RVV_I64
+ | AV_CPU_FLAG_RVV_F32 | AV_CPU_FLAG_RVV_F64;
+if (pairs[1].value & RISCV_HWPROBE_EXT_ZBA)
+ret |= AV_CPU_FLAG_RVB_ADDR;
+if (pairs[1].value & RISCV_HWPROBE_EXT_ZBB)
+ret |= AV_CPU_FLAG_RVB_BASIC;
+} else
+#endif
#if HAVE_GETAUXVAL
{
const unsigned long hwcap = getauxval(AT_HWCAP);
--
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] fftools/ffprobe: Avoid overflow when calculating DAR
Both the codecpar's width and height, and the SAR num and den are
ints, which can overflow. Cast to int64_t, which is what av_reduce
takes.
Without this, occasionally, display_aspect_ratio can be negative in
ffprobe's -show_stream output.
Signed-off-by: Derek Buitenhuis
---
fftools/ffprobe.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 0d4cd0b048..5b40dad527 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3324,8 +3324,8 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
if (sar.num) {
print_q("sample_aspect_ratio", sar, ':');
av_reduce(, ,
- par->width * sar.num,
- par->height * sar.den,
+ (int64_t) par->width * sar.num,
+ (int64_t) par->height * sar.den,
1024*1024);
print_q("display_aspect_ratio", dar, ':');
} else {
--
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] [RFC] 5 year plan & Inovation
> On May 3, 2024, at 6:54 AM, Ronald S. Bultje wrote: > > On Fri, May 3, 2024 at 7:33 AM Rémi Denis-Courmont wrote: > >> >> There is no technical plan how that would actually work in practice, and I >> don't think it is even feasible. Not to speak of a realistic plan who would >> actually implement it and in what time frame. >> > > To clarify: I myself much prefer gitlab's workflow and would use that if it > was available. I think providing a CLI-based workflow (which Anton and some > others have requested) is feasible and fair. If an email variant thereof > can be made and someone wants to fund it, I think that's reasonable. But it > shouldn't block allowing more people to convert to a gitlab-style workflow, > which I consider far superior over what we have now. End of clarification. I think it's useful to separate out CLI-based workflow from email based workflow. For example with GitHub you can use the gh command line tool (https://github.com/cli/cli) to do almost everything from the CLI. See outstanding pull requests, create a new pull request, check out a pull request, leave comments, approve, reject, etc. The only thing the official CLI tool itself doesn't offer is ability to add in-line comments. If one really wants to avoid the browser for leaving in-line comments there are solutions integrated with popular editors to do this directly from the editor. For those that like Neovim a full featured editor plugin like octo.nvim (https://github.com/pwntester/octo.nvim?tab=readme-ov-file#-pr-reviews) can be used to do everything including code reviews with inline comments. Similar solutions exist for Emacs. And the API is there to make something more customized if desired. For example a tool like "re" can open up $EDITOR and allow adding inline comments (https://github.com/jordanlewis/re). This is for Github but Gitlab is popular enough that I'd expect the same to exist there or at a minimum to be possible to bridge the gap (in general the github tooling is more mature). What doesn't exist (yet) is a way to keep people on the exact email based workflow we currently have, and have bi-directional sync with something like github or gitlab. Such a thing could probably be built, but it might be worth first trying to see if those that insist on sticking with the CLI can use one of the existing CLI based workflows. - Cosmin ___ 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] RISC-V review process notice
Hi, To preserve my own sanity as a volunteer, and until/unless FFmpeg moves to a different code review workflow, I will *only* be reviewing code submitted in git-format-patch format. That is to say in-line. If you do not like it, you are most welcome to support a change to a non-mail- based workflow, or to propose somebody else to review in my stead. Thanks for your attention, -- レミ・デニ-クールモン 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] [PATCH] avformat/mxfdec: only check index_edit_rate when calculating the index tables
tor 2024-05-02 klockan 23:01 +0200 skrev Marton Balint: > > > On Mon, 29 Apr 2024, Tomas Härdin wrote: > > > mån 2024-04-15 klockan 21:34 +0200 skrev Marton Balint: > > > Commit ed49391961999f028e0bc55767d0eef6eeb15e49 started rejecting > > > negative > > > index segment edit rates to avoid negative av_rescale parameters. > > > There are two > > > problems with this: > > > > > > 1) there is already a validation for zero (uninitialized) rates > > > later > > > on > > > 2) it rejects files with 0/0 index edit rates which do exist and > > > we > > > should > > > continue to support those > > > > There are no such files in FATE last time I checked. At the very > > least > > we need to know which vendor is producing such broken files. > > > > Without tests covering the workflows we want to support, we have no > > confidence in refactoriing. This leads to cargo culting. And to be > > sure, every workflow we support means a non-trivial amount of work, > > especially when it comes to MXF. > > I can add a comment to the code or the commit message, we did this > plenty > of times in the past. The broken software is Marquise Technologies MT > Mediabase 4.7.2 by the way. I can also rework the patch to keep > rejecting > negative values and only allow zero, as that is the only thing I > *know* to > exist. We could also tell Marquise Technologies to fix their software. MXF is a living ecosystem > If we add a new FATE file for every fixed file or workflow, the > amount of > FATE samples (and the time fate will run) will increase > significantly, I > am not sure that is intended. "Support any old workflow but don't add tests for them" is a ridiculous position. It also prevents refactoring. There are real costs to supporting workflows that no one uses. Hence why I mention SLAs. The only people interested in MXF are professionals. > In this case, I could only craft an MXF > file, because I don't have access to the software. Yes we can craft arbitrarily broken files. That doesn't help anyone. It's just cargo culting. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Le perjantaina 3. toukokuuta 2024, 15.58.50 EEST Ondřej Fiala a écrit : > > And in the end, I could be wrong, but I haven't seen you doing much code > > review here. This is all about optimising the workflow for people doing > > code reviews and code merges, so why do you even care? > > Because your "optimizations" will make contributing to ffmpeg significantly > harder for people like me. All they do is make the first contribution harder because you have to create an account on, and clone the repository within, the web forge. Considering the distribution between first-time contributions versus reviews and further-time contributions, that is a very obviously worthy tradeoff. Note that I don't particularly prefer Gitlab vs email for submitting code. They both have their pros and cons, and I do not really like either of them. But Gitlab is so much easier for code review and merge, and it looks to me that the shortage of reviewers is even more pressing than developers here. The argument that people can't use web forges because they require too powerful computer system is bollocks. A system that can't show the Gitlab frontend is not going to be able to compile FFmpeg, forget run the test suite, in any practical time frame. Not to deny that there are performance challenges, but those lie on the server side. You can't expect the whole community to accomodate your unwillingness to run a web browser or update a ridiculous underprovisioned computer system. -- レミ・デニ-クールモン 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] [RFC] 5 year plan & Inovation
Le perjantaina 3. toukokuuta 2024, 16.54.14 EEST Ronald S. Bultje a écrit : > To clarify: I myself much prefer gitlab's workflow and would use that if it > was available. I think providing a CLI-based workflow (which Anton and some > others have requested) is feasible and fair. If an email variant thereof > can be made and someone wants to fund it, I think that's reasonable. But it > shouldn't block allowing more people to convert to a gitlab-style workflow, > which I consider far superior over what we have now. End of clarification. You can't have the cake and eat it. If we have to wait for a CLI workflow, for which no credible development plan exist, then we are stuck with email, and this is exactly "block[ing] allowing more prople to convert to a gitlab-style workflow". -- 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".
[FFmpeg-devel] [PATCH] avcodec/allcodecs: Remove LIBX264_CONST
Possible since 71669f2ad54d92a40dc2748cd5bd6ca4c8651231. Signed-off-by: Andreas Rheinhardt --- libavcodec/allcodecs.c | 11 +-- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index f4705651fb..b102a8069e 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -28,7 +28,6 @@ #include #include "config.h" -#include "config_components.h" #include "libavutil/thread.h" #include "codec.h" #include "codec_id.h" @@ -805,15 +804,7 @@ extern const FFCodec ff_libvpx_vp9_decoder; extern const FFCodec ff_libwebp_anim_encoder; extern const FFCodec ff_libwebp_encoder; extern const FFCodec ff_libx262_encoder; -#if CONFIG_LIBX264_ENCODER -#include -#if X264_BUILD < 153 -#define LIBX264_CONST -#else -#define LIBX264_CONST const -#endif -extern LIBX264_CONST FFCodec ff_libx264_encoder; -#endif +extern const FFCodec ff_libx264_encoder; extern const FFCodec ff_libx264rgb_encoder; extern FFCodec ff_libx265_encoder; extern const FFCodec ff_libxeve_encoder; -- 2.40.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] [RFC] 5 year plan & Inovation
Hi, On Fri, May 3, 2024 at 7:33 AM Rémi Denis-Courmont wrote: > > > Le 3 mai 2024 14:28:59 GMT+03:00, "Ronald S. Bultje" > a écrit : > >Hi, > > > >On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont > wrote: > > > >> Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" < > rsbul...@gmail.com> > >> a écrit : > >> >On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara < > >> vittorio.giov...@gmail.com> > >> >wrote: > >> >> I believe the path forward would be designing a system that can > >> accommodate > >> >> both workflows > >> > > >> >I agree with this. > >> > >> I vehemently disagree with this. > >> > >> Unless you are volunteering to write such a tool, this is wishful > thinking > >> and the result is that we stick to the mailing list workflow. > >> > > > >Can you explain your disapproval? Is it that it needs work? Or money? Or > do > >you just think it's a bad idea? Or something else? > > There is no technical plan how that would actually work in practice, and I > don't think it is even feasible. Not to speak of a realistic plan who would > actually implement it and in what time frame. > To clarify: I myself much prefer gitlab's workflow and would use that if it was available. I think providing a CLI-based workflow (which Anton and some others have requested) is feasible and fair. If an email variant thereof can be made and someone wants to fund it, I think that's reasonable. But it shouldn't block allowing more people to convert to a gitlab-style workflow, which I consider far superior over what we have now. End of clarification. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Le 3 mai 2024 15:58:50 GMT+03:00, "Ondřej Fiala" a écrit : >On Fri May 3, 2024 at 7:46 AM CEST, Rémi Denis-Courmont wrote: >> Le 2 mai 2024 22:32:16 GMT+03:00, "Ondřej Fiala" a écrit >> : >> >On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote: >> >> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit : >> >> > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote: >> >> > > I don't use Gmail, and using email for review still sucks. No matter >> >> > > how >> >> > > you slice it, email was not meant for threaded code reviews. >> >> > >> >> > Email was not meant for a lot of what it's used for today. >> >> >> >> And Gitlab and Github are meant for what they are used. >> >> That's the whole point. >> >This argument can actually go in both directions >> >> No, it can't. >I wish your replies were more constructive Then don't make ridiculously extreme arguments. >> > Since the Web and web >> >browsers weren't meant for performing code review either. >> >> I was obviously and explicitly talking about Github and Gitlab web >> applications, not the browsers. You're being ridiculous. >A web application is just a bunch of JavaScript and/or Web Assembly >running in a web browser that supports it. By that logic, your mail client is just a bunch of C or C++ files compiled together, and your processor is just a bunch of VHDL synthesised into silicon. This is called a reduction to absurd fallacy. I don't care how much you despise web development. That doesn't change the *fact* that Gitlab is designed to manage code reviews and merges and mail clients are *not*. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri May 3, 2024 at 7:46 AM CEST, Rémi Denis-Courmont wrote: > > Since the Web and web > >browsers weren't meant for performing code review either. > > I was obviously and explicitly talking about Github and Gitlab web > applications, not the browsers. You're being ridiculous. By the way, speaking of ridiculous, I really recommend you read this: https://drewdevault.com/2020/03/18/Reckless-limitless-scope.html ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Thu May 2, 2024 at 10:06 PM CEST, epirat07 wrote: > On 2 May 2024, at 21:32, Ondřej Fiala wrote: > > Of course, the quality of your toolings matters a lot. If your email client > > can't pipe a bunch of emails to a shell command, it's not fit for being used > > to review git patches. On the other hand, if you possess just some basic > > shell > > scripting skills, you can make it do pretty cool things. > > So I first have to get proficient in some shell scripting gymnastics Are you serious that as an open-source dev, you can't even write such a trivial shell function? > (and also switch to a completely different terminal-based mail client) > so I can do proper reviews? You can use any mail client that works well for you, I just showed what I personally like. I remember seeing Greg KH (IIRC) using mutt for the same purpose and I am sure it worked well for him as well. This is quite unlike the GitHub/GitLab situation where if you use anything other than a recent mainstream browser, it does not work AT ALL. > Thats incredibly gatekeeping. Hardly. > > Since you felt that there is no way to see additional context, I put > > together > > a quick demo[1] showing how easily you can review all files affected by a > > patch > > and look at *all* the context. Of course, you could do a bunch of other > > things to > > adjust the email-based workflow as desired. And don't forget this is just a > > demo; > > I am sure you could come up with something better. > > > > [1] https://paste.c-net.org/HansenWeekends > > That seems to download some binary file? I have no idea what it is supposed > to be. Sorry about that; the site picked the filename and I forgot to say that it's an mkv file. Just save it with an `.mkv` suffix and play it with ffplay or similar. > >> Not everybody can pick a decent email provider with outbound SMTP and a > >> good > >> reputation. Also not everybody gets to pick their mail agent or their ISP. > >> > >> You are just being unwittingly elistist here. > > I must admit I did not realize how bad some email/internet providers can be > > when writing this, as I have a fairly average setup and never ran into such > > issues. > > > > But the problem with accessibility is not aleviated by switching away from > > email, since those forges aren't universally accessible either. I remember > > how > > I used to run Pale Moon like 2 years ago. In case you don't know, it's a > > Firefox > > fork maintained by a small team. GitHub didn't run on it. Oh, sorry, you > > don't > > care about GitHub. But they share the same desig -- hugely complex "web app" > > that only runs on latest version of major browsers. Everyone else is > > excluded. > > When I wanted to contribute to a project I really cared about, I had to > > download > > mainline Firefox and do it over that. If I cared even a bit less about it, I > > wouldn't bother. > > > > So how is that any different? > > How is it different to download a well maintained recent software and open a > website, > in comparison to learn how to setup a (complex) combination of tools just to > be able > to easily contribute? It's not a complex combination; it's just git, an email client, and standard command line tooling. But sure, if you don't even know basic shell, it might seem complex. I assumed anyone contributing to a C library with accompanying command-line utilities would know such basics. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri May 3, 2024 at 7:46 AM CEST, Rémi Denis-Courmont wrote: > Le 2 mai 2024 22:32:16 GMT+03:00, "Ondřej Fiala" a écrit : > >On Thu May 2, 2024 at 4:38 PM CEST, Rémi Denis-Courmont wrote: > >> Le torstaina 2. toukokuuta 2024, 17.25.06 EEST Ondřej Fiala a écrit : > >> > On Wed May 1, 2024 at 7:27 AM CEST, Rémi Denis-Courmont wrote: > >> > > I don't use Gmail, and using email for review still sucks. No matter > >> > > how > >> > > you slice it, email was not meant for threaded code reviews. > >> > > >> > Email was not meant for a lot of what it's used for today. > >> > >> And Gitlab and Github are meant for what they are used. > >> That's the whole point. > >This argument can actually go in both directions > > No, it can't. I wish your replies were more constructive. > > Since the Web and web > >browsers weren't meant for performing code review either. > > I was obviously and explicitly talking about Github and Gitlab web > applications, not the browsers. You're being ridiculous. A web application is just a bunch of JavaScript and/or Web Assembly running in a web browser that supports it. The technologies that these "applications" rely on are often available only in latest mainstream browsers, everyone else is excluded. I experienced such exclusion first hand in the past, which I mentioned in the email you're replying to. I really don't see how I am being ridiculous by pointing that out. > Your OS was originally meant to run bash, not a mail client, by that logic. I really don't see how that follows the same logic, since a general purpose OS is meant to run anything you want it to (that's the meaning of "general purpose"), while a web browser was originally meant to, guess what, browse the web. Besides, the first version of Linux was released in 1991 and email existed for many years at that time already. > And in the end, I could be wrong, but I haven't seen you doing much code > review here. This is all about optimising the workflow for people doing > code reviews and code merges, so why do you even care? Because your "optimizations" will make contributing to ffmpeg significantly harder for people like me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Le 3 mai 2024 14:28:59 GMT+03:00, "Ronald S. Bultje" a écrit : >Hi, > >On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont wrote: > >> Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" >> a écrit : >> >On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara < >> vittorio.giov...@gmail.com> >> >wrote: >> >> I believe the path forward would be designing a system that can >> accommodate >> >> both workflows >> > >> >I agree with this. >> >> I vehemently disagree with this. >> >> Unless you are volunteering to write such a tool, this is wishful thinking >> and the result is that we stick to the mailing list workflow. >> > >Can you explain your disapproval? Is it that it needs work? Or money? Or do >you just think it's a bad idea? Or something else? There is no technical plan how that would actually work in practice, and I don't think it is even feasible. Not to speak of a realistic plan who would actually implement it and in what time frame. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
Hi, On Fri, May 3, 2024 at 1:53 AM Rémi Denis-Courmont wrote: > Le 2 mai 2024 21:38:13 GMT+03:00, "Ronald S. Bultje" > a écrit : > >On Thu, May 2, 2024 at 1:44 PM Vittorio Giovara < > vittorio.giov...@gmail.com> > >wrote: > >> I believe the path forward would be designing a system that can > accommodate > >> both workflows > > > >I agree with this. > > I vehemently disagree with this. > > Unless you are volunteering to write such a tool, this is wishful thinking > and the result is that we stick to the mailing list workflow. > Can you explain your disapproval? Is it that it needs work? Or money? Or do you just think it's a bad idea? Or something else? Ronald ___ 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".
