[FFmpeg-devel] [PATCH] web: remove myself from FFmpeg consulting page
Attached. From dbee6548020b42f4559042fd6a50fa4fa35121ff Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Thu, 7 Dec 2023 08:45:23 +0100 Subject: [PATCH] remove myself from FFmpeg consulting page --- src/consulting | 12 1 file changed, 12 deletions(-) diff --git a/src/consulting b/src/consulting index 70a88e5..1e205b5 100644 --- a/src/consulting +++ b/src/consulting @@ -82,18 +82,6 @@ E.g.: - - - Paul B Mahol - -Paul is located in Croatia and is available for contracting work. He has -worked on FFmpeg since 2011 and has been a maintainer since 2012. He has -experience with various codecs, containers, filters and reverse -engineering. You can contact him by email at -onemda at gmail dot com. - - - Thilo Borgmann -- 2.42.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] doc/examples/qsv_transcode: EINVAL is more appropriate and ENAVAIL will fail build with visual studio
On Do, 2023-12-07 at 06:44 +, hung kuishing wrote:
> Signed-off-by: clarkh
> ---
> doc/examples/qsv_transcode.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
> index 48128b200c..972126800b 100644
> --- a/doc/examples/qsv_transcode.c
> +++ b/doc/examples/qsv_transcode.c
> @@ -62,10 +62,10 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
> return 0;
> key = strtok(optstr, " ");
> if (key == NULL)
> - return AVERROR(ENAVAIL);
> + return AVERROR(EINVAL);
> value = strtok(NULL, " ");
> if (value == NULL)
> - return AVERROR(ENAVAIL);
> + return AVERROR(EINVAL);
> av_dict_set(opt, key, value, 0);
> do {
> key = strtok(NULL, " ");
> @@ -73,7 +73,7 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
> return 0;
> value = strtok(NULL, " ");
> if (value == NULL)
> - return AVERROR(ENAVAIL);
> + return AVERROR(EINVAL);
> av_dict_set(opt, key, value, 0);
> } while(key != NULL);
> return 0;
> @@ -181,7 +181,7 @@ static int open_input_file(char *filename)
> break;
> default:
> fprintf(stderr, "Codec is not supportted by qsv\n");
> - return AVERROR(ENAVAIL);
> + return AVERROR(EINVAL);
> }
>
> if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
LGTM, thanks for fixing the issue.
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".
[FFmpeg-devel] [PATCH] MAINTAINERS: remove myself from FFmpeg
Attached. From b249499fccb49705ade14362875ebf4d22628fa4 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Thu, 7 Dec 2023 08:27:14 +0100 Subject: [PATCH] MAINTAINERS: remove myself from FFmpeg Signed-off-by: Paul B Mahol --- MAINTAINERS | 55 - 1 file changed, 55 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 57137e1d6d..b517ed8342 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -144,7 +144,6 @@ Codecs: bgmc.c, bgmc.hThilo Borgmann binkaudio.c Peter Ross cavs* Stefan Gehrer - cdxl.cPaul B Mahol celp_filters.*Vitor Sessak cinepak.c Roberto Togni cinepakenc.c Rl / Aetey G.T. AB @@ -163,7 +162,6 @@ Codecs: dv.c Roman Shaposhnik dvbsubdec.c Anshul Maheshwari eacmv*, eaidct*, eat* Peter Ross - evrc* Paul B Mahol exif.c, exif.hThilo Borgmann ffv1* Michael Niedermayer ffwavesynth.c Nicolas George @@ -217,7 +215,6 @@ Codecs: nvdec*, nvenc*Timo Rothenpieler omx.c Martin Storsjo, Aman Gupta opus* Rostislav Pehlivanov - paf.* Paul B Mahol pcx.c Ivo van Poorten pgssubdec.c Reimar Doeffinger ptx.c Ivo van Poorten @@ -239,16 +236,13 @@ Codecs: srt* Aurelien Jacobs sunrast.c Ivo van Poorten svq3.cMichael Niedermayer - tak* Paul B Mahol truemotion1* Mike Melanson tta.c Alex Beregszaszi, Jaikrishnan Menon - ttaenc.c Paul B Mahol txd.c Ivo van Poorten v4l2_*Jorge Ramirez-Ortiz vc2* Rostislav Pehlivanov vcr1.cMichael Niedermayer videotoolboxenc.c Rick Kern, Aman Gupta - vima.cPaul B Mahol vorbisdec.c Denes Balatoni, David Conrad vorbisenc.c Oded Shimon vp3* Mike Melanson @@ -262,9 +256,7 @@ Codecs: wmavoice.cRonald S. Bultje wmv2.cMichael Niedermayer xan.c Mike Melanson - xbm* Paul B Mahol xface Stefano Sabatini - xwd* Paul B Mahol Hardware acceleration: dxva2*Hendrik Leppkes, Laurent Aimar, Steve Lhomme @@ -308,64 +300,33 @@ Generic parts: motion_estimation.c Davinder Singh Filters: - f_drawgraph.c Paul B Mahol - af_adelay.c Paul B Mahol - af_aecho.cPaul B Mahol - af_afade.cPaul B Mahol af_amerge.c Nicolas George - af_aphaser.c Paul B Mahol af_aresample.cMichael Niedermayer - af_astats.c Paul B Mahol af_atempo.c Pavel Koshevoy - af_biquads.c Paul B Mahol - af_chorus.c Paul B Mahol - af_compand.c Paul B Mahol af_firequalizer.c Muhammad Faiz af_hdcd.c Burt P. - af_ladspa.c Paul B Mahol af_loudnorm.c Kyle Swanson af_pan.c Nicolas George - af_sidechaincompress.cPaul B Mahol - af_silenceremove.cPaul B Mahol - avf_aphasemeter.c Paul B Mahol - avf_avectorscope.cPaul B Mahol avf_showcqt.c Muhammad Faiz - vf_blend.cPaul B Mahol vf_bwdif Thomas Mundt (CC ) vf_chromakey.cTimo Rothenpieler - vf_colorchannelmixer.cPaul B Mahol vf_colorconstancy.c Mina Sami(CC ) - vf_colorbalance.c Paul B Mahol vf_colorkey.c Timo Rothenpieler - vf_colorlevels.c Paul B Mahol vf_coreimage.mThilo Borgman
Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder
Quoting James Almer (2023-12-06 21:49:45) > On 12/2/2023 12:53 PM, Anton Khirnov wrote: > > Its author not only failed to add any tests, as is required by the > > development rules, but continues to actively refuse to do so. > > > > Untested decoders are worse than useless, so remove it. > > --- > > Changelog | 2 +- > > libavcodec/Makefile| 1 - > > libavcodec/allcodecs.c | 1 - > > libavcodec/qoadec.c| 170 - > > 4 files changed, 1 insertion(+), 173 deletions(-) > > delete mode 100644 libavcodec/qoadec.c > > As there are tests now afaics, this patch can be withdrawn. Of course, actually pushing it was never the point of this patch. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] doc/examples/qsv_transcode: EINVAL is more appropriate and ENAVAIL will fail build with visual studio
Signed-off-by: clarkh
---
doc/examples/qsv_transcode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
index 48128b200c..972126800b 100644
--- a/doc/examples/qsv_transcode.c
+++ b/doc/examples/qsv_transcode.c
@@ -62,10 +62,10 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
return 0;
key = strtok(optstr, " ");
if (key == NULL)
-return AVERROR(ENAVAIL);
+return AVERROR(EINVAL);
value = strtok(NULL, " ");
if (value == NULL)
-return AVERROR(ENAVAIL);
+return AVERROR(EINVAL);
av_dict_set(opt, key, value, 0);
do {
key = strtok(NULL, " ");
@@ -73,7 +73,7 @@ static int str_to_dict(char* optstr, AVDictionary **opt)
return 0;
value = strtok(NULL, " ");
if (value == NULL)
-return AVERROR(ENAVAIL);
+return AVERROR(EINVAL);
av_dict_set(opt, key, value, 0);
} while(key != NULL);
return 0;
@@ -181,7 +181,7 @@ static int open_input_file(char *filename)
break;
default:
fprintf(stderr, "Codec is not supportted by qsv\n");
-return AVERROR(ENAVAIL);
+return AVERROR(EINVAL);
}
if (!(decoder_ctx = avcodec_alloc_context3(decoder)))
--
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] libavformat/dashdec.c Fix for ticket #7395
Evgeniy Pantyuhin via ffmpeg-devel
于2023年12月7日周四 04:32写道：
>
> Signed-off-by: Evgeniy
> ---
> libavformat/dashdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 29d4680..36e4719 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -768,7 +768,7 @@ static int resolve_content_path(AVFormatContext *s, const
> char *url, int *max_ur
> baseurl = xmlNodeGetContent(node);
> root_url = (av_strcasecmp(baseurl, "")) ? baseurl : path;
> if (node) {
> -xmlNodeSetContent(node, root_url);
> +xmlNodeSetContent(node, xmlEncodeEntitiesReentrant(NULL, root_url));
> updated = 1;
> }
>
> --
> 2.40.0.windows.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".
LGTM
Thanks
Steven
___
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 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote:
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 2cfb3fcf97..f9b18a2c35 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
>
> validate_avframe_allocation(avctx, frame);
>
> +if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type ==
> AVMEDIA_TYPE_VIDEO) {
> +uint32_t color[4] = {0};
> +ptrdiff_t linesize[4] = {frame->linesize[0], frame->linesize[1],
> frame->linesize[2], frame->linesize[3]};
> +av_image_fill_color(frame->data, linesize, frame->format, color,
> frame->width, frame->height);
>
I think it's be safer to add a return check here
--
Vittorio
___
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/3] lavu/hwcontext_d3d11va: Add option vendor_id
On Di, 2023-12-05 at 08:18 +, Xiang, Haihao wrote:
> On Di, 2023-11-28 at 12:42 +0800, Xiang, Haihao wrote:
> > From: Artem Galin
> >
> > User may choose the hardware via option vendor_id when multiple
> > hardwares are available.
> >
> > Signed-off-by: Artem Galin
> > Signed-off-by: Haihao Xiang
> > ---
> > libavutil/hwcontext_d3d11va.c | 59 ++-
> > 1 file changed, 58 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/hwcontext_d3d11va.c b/libavutil/hwcontext_d3d11va.c
> > index cc8c97d2b6..2fd3561c88 100644
> > --- a/libavutil/hwcontext_d3d11va.c
> > +++ b/libavutil/hwcontext_d3d11va.c
> > @@ -552,6 +552,47 @@ static void d3d11va_device_uninit(AVHWDeviceContext
> > *hwdev)
> > }
> > }
> >
> > +static int d3d11va_device_find_adapter_by_vendor_id(AVHWDeviceContext *ctx,
> > uint32_t flags, const char *vendor_id)
> > +{
> > + HRESULT hr;
> > + IDXGIAdapter *adapter = NULL;
> > + IDXGIFactory2 *factory;
> > + int adapter_id = 0;
> > + long int id = strtol(vendor_id, NULL, 0);
> > +
> > + hr = mCreateDXGIFactory(&IID_IDXGIFactory2, (void **)&factory);
> > + if (FAILED(hr)) {
> > + av_log(ctx, AV_LOG_ERROR, "CreateDXGIFactory returned error\n");
> > + return -1;
> > + }
> > +
> > + while (IDXGIFactory2_EnumAdapters(factory, adapter_id++, &adapter) !=
> > DXGI_ERROR_NOT_FOUND) {
> > + ID3D11Device* device = NULL;
> > + DXGI_ADAPTER_DESC adapter_desc;
> > +
> > + hr = mD3D11CreateDevice(adapter, D3D_DRIVER_TYPE_UNKNOWN, NULL,
> > flags, NULL, 0, D3D11_SDK_VERSION, &device, NULL, NULL);
> > + if (FAILED(hr)) {
> > + av_log(ctx, AV_LOG_DEBUG, "D3D11CreateDevice returned error,
> > try
> > next adapter\n");
> > + IDXGIAdapter_Release(adapter);
> > + continue;
> > + }
> > +
> > + hr = IDXGIAdapter2_GetDesc(adapter, &adapter_desc);
> > + ID3D11Device_Release(device);
> > + IDXGIAdapter_Release(adapter);
> > + if (FAILED(hr)) {
> > + av_log(ctx, AV_LOG_DEBUG, "IDXGIAdapter2_GetDesc returned
> > error,
> > try next adapter\n");
> > + continue;
> > + } else if (adapter_desc.VendorId == id) {
> > + IDXGIFactory2_Release(factory);
> > + return adapter_id - 1;
> > + }
> > + }
> > +
> > + IDXGIFactory2_Release(factory);
> > + return -1;
> > +}
> > +
> > static int d3d11va_device_create(AVHWDeviceContext *ctx, const char
> > *device,
> > AVDictionary *opts, int flags)
> > {
> > @@ -563,6 +604,7 @@ static int d3d11va_device_create(AVHWDeviceContext *ctx,
> > const char *device,
> > UINT creationFlags = D3D11_CREATE_DEVICE_VIDEO_SUPPORT;
> > int is_debug = !!av_dict_get(opts, "debug", NULL, 0);
> > int ret;
> > + int adapter = -1;
> >
> > // (On UWP we can't check this.)
> > #if !HAVE_UWP
> > @@ -581,10 +623,25 @@ static int d3d11va_device_create(AVHWDeviceContext
> > *ctx,
> > const char *device,
> > }
> >
> > if (device) {
> > + adapter = atoi(device);
> > + } else {
> > + AVDictionaryEntry *e = av_dict_get(opts, "vendor_id", NULL, 0);
> > + if (e && e->value) {
> > + adapter = d3d11va_device_find_adapter_by_vendor_id(ctx,
> > creationFlags, e->value);
> > + if (adapter < 0) {
> > + av_log(ctx, AV_LOG_ERROR, "Failed to find d3d11va adapter
> > by
> > "
> > + "vendor id %s\n", e->value);
> > + return AVERROR_UNKNOWN;
> > + }
> > + }
> > + }
> > +
> > + if (adapter >= 0) {
> > IDXGIFactory2 *pDXGIFactory;
> > +
> > + av_log(ctx, AV_LOG_VERBOSE, "Selecting d3d11va adapter %d\n",
> > adapter);
> > hr = mCreateDXGIFactory(&IID_IDXGIFactory2, (void
> > **)&pDXGIFactory);
> > if (SUCCEEDED(hr)) {
> > - int adapter = atoi(device);
> > if (FAILED(IDXGIFactory2_EnumAdapters(pDXGIFactory, adapter,
> > &pAdapter)))
> > pAdapter = NULL;
> > IDXGIFactory2_Release(pDXGIFactory);
>
> I'll merge this patchset if there are no more comments for v2
Pushed,
Thanks
Haihao
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tests/fate: add pixelize filter tests
On Wed, Dec 06, 2023 at 11:20:06AM +0100, Paul B Mahol wrote: > Attached. > fate/filter-video.mak|9 + > ref/fate/filter-pixelize-avg |1 + > ref/fate/filter-pixelize-max |1 + > ref/fate/filter-pixelize-min |1 + > 4 files changed, 12 insertions(+) > 0cf8d90a5adf0565d3085b3bc11e49fdc534 > 0001-tests-fate-add-pixelize-filter-tests.patch > From c17589e4fc6b38013d6b0b14feeac50e00bb3305 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Wed, 6 Dec 2023 11:18:35 +0100 > Subject: [PATCH] tests/fate: add pixelize filter tests > > Signed-off-by: Paul B Mahol > --- > tests/fate/filter-video.mak| 9 + > tests/ref/fate/filter-pixelize-avg | 1 + > tests/ref/fate/filter-pixelize-max | 1 + > tests/ref/fate/filter-pixelize-min | 1 + > 4 files changed, 12 insertions(+) > create mode 100644 tests/ref/fate/filter-pixelize-avg > create mode 100644 tests/ref/fate/filter-pixelize-max > create mode 100644 tests/ref/fate/filter-pixelize-min Tested on mingw32/64, x86 64&32 linux, arm & mips qemu all work fine thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you think the mosad wants you dead since a long time then you are either wrong or dead since a long time. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tests/fate: add median filter test
On Wed, Dec 06, 2023 at 12:21:02PM +0100, Paul B Mahol wrote: > Attached. > fate/filter-video.mak |3 +++ > ref/fate/filter-median |1 + > 2 files changed, 4 insertions(+) > 13f347a427b22bbb5ea4959ad092435d6f10c8d9 > 0001-tests-fate-add-median-filter-test.patch > From 2c54553b83f2b67f781c67cb72deb4a5f267a8f1 Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Wed, 6 Dec 2023 12:17:54 +0100 > Subject: [PATCH] tests/fate: add median filter test > > Signed-off-by: Paul B Mahol > --- > tests/fate/filter-video.mak | 3 +++ > tests/ref/fate/filter-median | 1 + > 2 files changed, 4 insertions(+) > create mode 100644 tests/ref/fate/filter-median Tested on mingw32/64, x86 64&32 linux, arm & mips qemu all work fine thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
Hi, On Wed, Dec 6, 2023 at 3:23 AM Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > doc/codecs.texi| 14 ++ > libavcodec/avcodec.h | 4 > libavcodec/decode.c| 6 ++ > libavcodec/options_table.h | 1 + > libavcodec/version.h | 2 +- > 6 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 416e2bec5e..f839504a64 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,9 @@ The last version increases of all libraries were on > 2023-02-09 > > API changes, most recent first: > > +2023-12-xx - xxx - lavc 60.36.100 - avcodec.h > + Add AV_CODEC_FLAG_CLEAR. > + > 2023-12-xx - xxx - lavu 58.33.100 - imgutils.h >Add av_image_fill_color() > > diff --git a/doc/codecs.texi b/doc/codecs.texi > index 5b950b4560..0504a535f2 100644 > --- a/doc/codecs.texi > +++ b/doc/codecs.texi > @@ -76,6 +76,20 @@ Apply interlaced motion estimation. > Use closed gop. > @item output_corrupt > Output even potentially corrupted frames. > +@item clear > +Clear the contents of the video buffer before decoding the next picture > to it. > + > +Usually if only a part of a picture is affected by a decode error then the > +decoder (if it implements error concealment) tries to hide it by > interpolating > +pixels from neighbouring areas or in some cases from the previous frame. > Even > +without error concealment it is quite likely that the affected area will > +contain pixels from an earlier frame, due to frame pooling. > No comment on the patch itself, but wouldn't our users (and the C standard itself) consider it a security issue to return stale (or worse: uninitialized) data while pretending that it's safe to access? I thought touching uninitialized data was UB. 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] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
On date Wednesday 2023-12-06 09:22:20 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > doc/codecs.texi| 14 ++ > libavcodec/avcodec.h | 4 > libavcodec/decode.c| 6 ++ > libavcodec/options_table.h | 1 + > libavcodec/version.h | 2 +- > 6 files changed, 29 insertions(+), 1 deletion(-) LGTM but I'll let someone with more familiarity of the lavc internals comment on this. ___ 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 6/7] avutil/imgutils: add new function av_image_fill_color()
On date Wednesday 2023-12-06 09:22:19 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/APIchanges | 3 +++ > libavutil/imgutils.c | 4 ++-- > libavutil/imgutils.h | 30 ++ > libavutil/version.h | 2 +- > 4 files changed, 36 insertions(+), 3 deletions(-) > > diff --git a/doc/APIchanges b/doc/APIchanges > index 4a2dc1c44f..416e2bec5e 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09 > > API changes, most recent first: > > +2023-12-xx - xxx - lavu 58.33.100 - imgutils.h > + Add av_image_fill_color() nit++: add missing dot? [...] LGTM otherwise (no need to send another patch). ___ 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 5/7] avutil/imgutils: factorize a fill color function
On date Wednesday 2023-12-06 09:22:18 +0100, Marton Balint wrote: > In preparation for making it public. > > Signed-off-by: Marton Balint > --- > libavutil/imgutils.c | 103 +++ > 1 file changed, 64 insertions(+), 39 deletions(-) LGTM, 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 v6 01/14] vvcdec: add vvc decoder stub
On 12/5/2023 11:45 AM, Nuo Mi wrote: --- configure | 1 + libavcodec/Makefile | 1 + libavcodec/allcodecs.c | 1 + libavcodec/vvc/Makefile | 4 + libavcodec/vvc/vvcdec.c | 62 libavcodec/vvc/vvcdec.h | 204 6 files changed, 273 insertions(+) create mode 100644 libavcodec/vvc/Makefile create mode 100644 libavcodec/vvc/vvcdec.c create mode 100644 libavcodec/vvc/vvcdec.h I'll be squashing and applying this set later this week. ___ 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 4/7] avutil/imgutils: add support for 32bit pixel format for av_image_fill_black()
On date Wednesday 2023-12-06 09:22:17 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavutil/imgutils.c| 33 +++-- > tests/ref/fate/imgutils | 24 > 2 files changed, 35 insertions(+), 22 deletions(-) LGTM, 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 3/7] avutil/imgutils: fix av_image_fill_black() for some pixel formats
On date Wednesday 2023-12-06 09:22:16 +0100, Marton Balint wrote: > - Fixes YA formats, because previous code always assumed alpha as the 4th > component. > - Fixes PAL format (as long as 0 is black, as in a systematic palette), > because > previous code assumed it as limited Y. > - Fixes XYZ format because it does not need nonzero chroma components > - Fixes xv30be as the bitstream mode got merged to the non-bitstream mode. > > Signed-off-by: Marton Balint > --- > libavutil/imgutils.c| 49 +++-- > tests/ref/fate/imgutils | 14 ++-- > 2 files changed, 25 insertions(+), 38 deletions(-) Still LGTM. ___ 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/7] avutil/tests/imgutils: add tests for av_image_fill_black()
On date Wednesday 2023-12-06 09:22:15 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavutil/tests/imgutils.c | 61 +-- > tests/ref/fate/imgutils| 217 + > 2 files changed, 269 insertions(+), 9 deletions(-) LGTM, 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/7] avutil/tests/imgutils: factorize basic tests to new function
On date Wednesday 2023-12-06 09:22:14 +0100, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > libavutil/tests/imgutils.c | 68 ++ > 1 file changed, 39 insertions(+), 29 deletions(-) LGTM, 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 v7 0/7] webp: add support for animated WebP decoding
On Wed, Dec 06, 2023 at 02:34:58AM +0100, Thilo Borgmann via ffmpeg-devel wrote: > Still images fixed, includes FATE tests, VP8 decoder decoupled so there are > no more data races, fixed more asserts, fixed ffprobe regression. > > Patch 5/7 is still there for making changes in lavc/webp reviewable but shall > be stashed when pushing. > > -Thilo > > Josef Zlomek (2): > libavcodec/webp: add support for animated WebP decoding > libavformat/webp: add WebP demuxer > > Thilo Borgmann (5): > avcodec/webp: move definitions into header > avcodec/webp: remove unused definitions > avcodec/webp_parser: parse each frame into one packet > avcodec/webp: make init_canvas_frame static > fate: add test for animated WebP something in this patch leads to new warnings: ./ffmpeg -i fate-suite/exif/image_small.webp -vcodec copy -bitexact file-4087B.webp ./ffmpeg -i file-4087B.webp -f null - after this patchset ./ffmpeg -i fate-suite/exif/image_small.webp -vcodec copy -bitexact file-4087B.webp ./ffmpeg -i file-4087B.webp -f null - [webp @ 0x55a5284bcb80] EXIF chunk present, but Exif bit not set in the VP8X header something similar happens with "ALPHA chunk present, but alpha bit not set in the VP8X header" with ticket 4087/5_webp_a.webp thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is a danger to trust the dream we wish for rather than the science we have, -- Dr. Kenneth Brown 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 v3] ffmpeg CLI multithreading
Quoting Cosmin Stejerean via ffmpeg-devel (2023-12-06 21:29:11) > There is still a penalty as you could do asetnsamples without multi-threading > and get even higher performance, > but given the general benefits of multi-threading and the fact that it's > possible to increase the performance of this > usecase arbitrarily by using larger and larger frames I think that's an > acceptable tradeoff for this use case. Exactly, I don't think you can reasonably expect a generic transcoder to be optimally performant in all cases. Every major change like this is a tradeoff and we have to pick those that are most broadly useful. A transcoding setup that encodes PCM and throws it away is not particularly useful, and the picture could change quite a lot once you add actual encoding. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc: remove the QOA decoder
I ain't reading all of that Happy for you Or sorry that happened On Wed, Dec 6, 2023 at 3:47 PM Nicolas George wrote: > Vittorio Giovara (12023-12-05): > > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of > > literature about feature creep and how important it is to remove dead > code. > > You should read said literature before quoting it, you would learn the > difference between more features and feature creep: creeping features > make it harder to maintain core features. > > So, can you prove that this QOA decoder makes it harder to maintain the > framework of FFmpeg? No, you cannot. > > > Uhhh, but maybe I'm just misinterpreting your message, but that looks > like > > a very ignorant comparison. > > It is not ignorant at all, you show exactly the same argument structure. > > Homophobes cannot prove homosexuality causes objective and immediate > harm to anybody. > > You cannot prove that Paul's code causes objective and immediate harm to > the project. > > So homophobes resort to invoking a vague harm to society / youth / > whatever. > > So you resort to invoking a vague harm to a generation. > > You do it because you have a strong intuition that it is true. > > Homophobes have a strong intuition that it is true too. > > But intuition without arguments has no place in a debate, it cannot > convince anybody. > > And your intuition is just as wrong as the homophobes'. > > In this instance, your intuition is wrong because it applies to FFmpeg > what it knows about professional projects — open or closed source — > whereas FFmpeg is not a professional project but a Libre Software > projects whose most talented contributors work for fun. > > In a professional project, the time and effort of developers is limited > and must be focused on useful things. In a project like FFmpeg, the time > and effort that talented developers invest in the project grows as they > can work on fun tasks, even when said tasks are of limited usefulness. > > A sure way of killing a project like FFmpeg is to prevent people from > working on the things they find fun and try to force them to do useful > things instead, either by outright rejecting if you have the authority > or by drowning them with bickering and demands, like you did with > Michael and like you just ran Paul out. > > Good job. > > -- > Nicolas George > ___ > 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". > -- Vittorio ___ 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
On Wed, Dec 6, 2023 at 3:14 PM Nicolas George wrote: > Lie. > A summary of your proposal or a link to your suggestion would be appreciated. Without reference we're all shouting in the void. > I guess now that your side holds most of the power the mask is off. > > This mail you just sent should be enough to get you kicked out three > times over. > I actually chuckled at this line :-D But that will not happen, will it? > > Congratulations, you are on track to become FFmpeg's de-facto dictator, > just like you were libav's de-facto dictator and ran it to the ground > with your blatant disregard for users and disrespect for fellow > developers. > I don't think improving the ffmpeg CLI tools shows any "disregard for users" and having code in parallel shows a lot of respect to fellow developers since it makes our life easier. You seem fixed on a crusade of keeping the status quo, but the consensus you speak of is instead to move forward. Yes some very minor use cases might break or see degraded performance, but that's the point of a development branch - so that we can all improve the code before the next stable release > I hope Fabrice keeps control of the domain, so that we can revive FFmpeg > in a few years. > See? this is what i mean, you're still in 2011. It's time to move on Nicolas, for your own sake, and for respect to your fellow developers and the users you hold so dear -- Vittorio ___ 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] lavc: remove the QOA decoder
On 12/2/2023 12:53 PM, Anton Khirnov wrote: Its author not only failed to add any tests, as is required by the development rules, but continues to actively refuse to do so. Untested decoders are worse than useless, so remove it. --- Changelog | 2 +- libavcodec/Makefile| 1 - libavcodec/allcodecs.c | 1 - libavcodec/qoadec.c| 170 - 4 files changed, 1 insertion(+), 173 deletions(-) delete mode 100644 libavcodec/qoadec.c As there are tests now afaics, this patch can be withdrawn. ___ 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] lavc: remove the QOA decoder
Vittorio Giovara (12023-12-05): > Your attitude for "omgfeatures" is also pretty toxic, there are heaps of > literature about feature creep and how important it is to remove dead code. You should read said literature before quoting it, you would learn the difference between more features and feature creep: creeping features make it harder to maintain core features. So, can you prove that this QOA decoder makes it harder to maintain the framework of FFmpeg? No, you cannot. > Uhhh, but maybe I'm just misinterpreting your message, but that looks like > a very ignorant comparison. It is not ignorant at all, you show exactly the same argument structure. Homophobes cannot prove homosexuality causes objective and immediate harm to anybody. You cannot prove that Paul's code causes objective and immediate harm to the project. So homophobes resort to invoking a vague harm to society / youth / whatever. So you resort to invoking a vague harm to a generation. You do it because you have a strong intuition that it is true. Homophobes have a strong intuition that it is true too. But intuition without arguments has no place in a debate, it cannot convince anybody. And your intuition is just as wrong as the homophobes'. In this instance, your intuition is wrong because it applies to FFmpeg what it knows about professional projects — open or closed source — whereas FFmpeg is not a professional project but a Libre Software projects whose most talented contributors work for fun. In a professional project, the time and effort of developers is limited and must be focused on useful things. In a project like FFmpeg, the time and effort that talented developers invest in the project grows as they can work on fun tasks, even when said tasks are of limited usefulness. A sure way of killing a project like FFmpeg is to prevent people from working on the things they find fun and try to force them to do useful things instead, either by outright rejecting if you have the authority or by drowning them with bickering and demands, like you did with Michael and like you just ran Paul out. Good job. -- 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".
[FFmpeg-devel] [PATCH] libavformat/dashdec.c Fix for ticket #7395
Signed-off-by: Evgeniy
---
libavformat/dashdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 29d4680..36e4719 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -768,7 +768,7 @@ static int resolve_content_path(AVFormatContext *s, const
char *url, int *max_ur
baseurl = xmlNodeGetContent(node);
root_url = (av_strcasecmp(baseurl, "")) ? baseurl : path;
if (node) {
-xmlNodeSetContent(node, root_url);
+xmlNodeSetContent(node, xmlEncodeEntitiesReentrant(NULL, root_url));
updated = 1;
}
--
2.40.0.windows.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 v3] ffmpeg CLI multithreading
Also, the numbers I'm seeing on my 16-core Ryzen 9 5950X are quite different: * 5.0, your command:speed=3.25e+03x * 5.0, filter_complex: speed=5.29e+03x * 5.1, your command:speed=3.2e+03x * 5.1, filter_complex: speed=5.2e+03x * 6.0, your command:speed=2.44e+03x * 6.0, filter_complex: speed=3.44e+03x * 6.1, your command:speed=1.31e+03x * 6.1, filter_complex: speed=4.06e+03x * threading, your command:speed=3e+03x * threading, filter_complex:speed=4.1e+03x So while there is a drop from 5.0 to post-threading, it is not as dramatic, and threading is actually faster than 6.1. And finally you can get at least an order of magnitude faster by using a larger frame size. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
> On Dec 6, 2023, at 11:36 AM, Anton Khirnov wrote: > >> In some cases the performance penalty because of threading is quite >> significant: >> >> Example command line: >> >> ffmpeg -f lavfi -i sine -af volume=6dB -f null none >> >> After latest threading changes: speed=810x >> Before latest threading changes: speed=1.13e+03x >> With 6.0 branch: speed=1.43e+03x >> With 5.1 branch: speed=2.92e+03x >> >> This is a significant decline from 5.1, getting slower with each >> release... Is there anything that can be done about this? > > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames Larger frames would definitely help. With the command as is I get 4.75e+03x on 6.0 and 2.81e+03x on latest mutli-threading branch. However when adding asetnsamples this improves considerably. For example using asetnsamples=2048 as follows runs at 5.6e+03x on the multi-threading branch ./ffmpeg -f lavfi -i sine,asetnsamples=2048 -af volume=6dB -f null none and it can be further improved by increasing the asetnsamples values to 4096 for example (9.18e+03x). There is still a penalty as you could do asetnsamples without multi-threading and get even higher performance, but given the general benefits of multi-threading and the fact that it's possible to increase the performance of this usecase arbitrarily by using larger and larger frames I think that's an acceptable tradeoff for this use case. - 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] [ANNOUNCEMENT] Left FFmpeg; starting Librempeg
Today, effectively immediately, I officially Ieft the FFmpeg project. For new decoders/encoders/muxers/demuxers/filters/fixes/speedups/tests/cleanups etc. look at Librempeg project on github, source code will appear soon there. See you there. ___ 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
On Wed, Dec 06, 2023 at 11:27:06AM +0100, Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. I have a case that becomes really non deterministic for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x52e2e323 CRC=0x747761ba CRC=0x747761ba CRC=0x52e2e323 CRC=0x9d872a4b CRC=0x5f5cacfd CRC=0xda55c458 CRC=0x2eccf1c8 CRC=0x747761ba CRC=0x1a4775bd sample from here probably: https://samples.ffmpeg.org/V-codecs/mszh-zlib/ before: for i in `seq 10` ; do ./ffmpeg -v 0 -bitexact -i mszh-zlib/monika_zlib.avi -bitexact -t 1 -f crc - ; done CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 CRC=0x192dc994 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Into a blind darkness they enter who follow after the Ignorance, they as if into a greater darkness enter who devote themselves to the Knowledge alone. -- Isha Upanishad 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] lavfi: introduce textutils
Stefano Sabatini (12023-11-30): > Generalize drawtext utilities to make them usable in other filters. > This will be needed to introduce the QR code source and filter without > duplicating functionality. > --- > libavfilter/Makefile | 2 +- > libavfilter/textutils.c | 379 +++ > libavfilter/textutils.h | 182 + > libavfilter/vf_drawtext.c | 533 ++ > 4 files changed, 693 insertions(+), 403 deletions(-) > create mode 100644 libavfilter/textutils.c > create mode 100644 libavfilter/textutils.h Hi. I had kept this mail to point that this would greatly benefit from using AVWriter instead of BPrint, since it is a much more elegant API with the early design mistakes fixed, and to propose to work together to make it happen. But right now, anything feels more appealing than working on FFmpeg. 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] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > Would guess this is caused by overhead from tons of tiny frames. So > 1) generate larger frames > 2) use -filter_complex with no inputs instead of -f lavfi to eliminate >all overhead from demuxing, decoding, and demux-decode/decode-filter >inter-thread communication Or maybe the threading code is just very inefficient because, just like the BufferRef code, it is riddled with unnecessary indirections and dynamic allocations. We will never know because your attitude made sure nobody competent looked at it. But that is not an issue, because you will ignore Marton's objection just like your ignored mine. -- 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] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > As usual when someone disagrees with him, Nicolas converged to being > utterly unreasonable and deaf to all arguments. I see no point in Ad-hominem attack. > discussing this with him any further and intend to push the set > tomorrow, unless somebody else has substantial objections. > > I've considered asking for a TC vote, Stated intent to act without seeking consensus. > but as he is not suggesting any > viable alternative, Lie. I guess now that your side holds most of the power the mask is off. This mail you just sent should be enough to get you kicked out three times over. But that will not happen, will it? Congratulations, you are on track to become FFmpeg's de-facto dictator, just like you were libav's de-facto dictator and ran it to the ground with your blatant disregard for users and disrespect for fellow developers. I hope Fabrice keeps control of the domain, so that we can revive FFmpeg in a few years. -- 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] [PATCH v3] ffmpeg CLI multithreading
On Wed, Dec 6, 2023 at 5:30 AM Anton Khirnov wrote: > Hi, > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. > LGTM -- Vittorio ___ 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] tools/general_assembly: implement extra GA members
On Thu, Nov 23, 2023 at 10:14:23AM +0100, Anton Khirnov wrote:
> ---
> tools/general_assembly.pl | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/tools/general_assembly.pl b/tools/general_assembly.pl
> index 4c3208ccac..3bf65f3405 100755
> --- a/tools/general_assembly.pl
> +++ b/tools/general_assembly.pl
> @@ -13,6 +13,12 @@ use utf8;
> use DateTime;
> use DateTime::Format::ISO8601;
>
> +my @extra_members = (
> +# entries should be of the format
> +# [ , , ],
> +# ['Foo Bar', 'foo@bar', DateTime->new(year => 8613, month => 5, day =>
> 22)],
> +);
> +
> sub trim { my $s = shift; $s =~ s/^\s+|\s+$//g; return $s };
>
> sub print_help {
> @@ -29,7 +35,7 @@ sub print_help {
> my $print_full = 1;
> my $print_names = 0;
> my $print_emails = 0;
> -my $date = DateTime->now()->iso8601;
> +my $date_str = DateTime->now()->iso8601;
> my $help = 0;
>
> GetOptions(
> @@ -37,7 +43,7 @@ GetOptions(
> "names" => \$print_names,
> "emails" => \$print_emails,
> "help" => \$help,
> -"date=s" => \$date,
> +"date=s" => \$date_str,
> "h" => \$help,
> );
>
> @@ -76,7 +82,8 @@ sub get_date_range {
> return ($date_since, $date_until);
> }
>
> -my ($since, $until) =
> get_date_range(DateTime::Format::ISO8601->parse_datetime($date));
> +my $date = DateTime::Format::ISO8601->parse_datetime($date_str);
> +my ($since, $until) = get_date_range($date);
>
> my @shortlog = split /\n/, decode('UTF-8',
> `git log --pretty=format:"%aN <%aE>" --since="$since" --until="$until" |
> sort | uniq -c | sort -r`,
> @@ -108,6 +115,13 @@ foreach my $line (@shortlog) {
> $assembly{$name} = $email;
> }
>
> +foreach my $entry (@extra_members) {
> +my $elected = $entry->[2];
> +if ($date->is_between($elected,
> $elected->clone()->set_year($elected->year + 2))) {
tools/general_assembly.pl
Can't locate object method "is_between" via package "DateTime" at
tools/general_assembly.pl line 75.
is_between seems to have been added in 1.52 2020-02-29
So this is unavailable in several distros, it works with cpan though
but this shoould be docuemnted if it cannot be avoided
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Quoting Marton Balint (2023-12-06 20:29:01) > > > On Wed, 6 Dec 2023, Anton Khirnov wrote: > > > Hi, > > this should hopefully be the last version of this set. If nobody has new > > comments, I will push it in a few days. > > In some cases the performance penalty because of threading is quite > significant: > > Example command line: > > ffmpeg -f lavfi -i sine -af volume=6dB -f null none > > After latest threading changes: speed=810x > Before latest threading changes: speed=1.13e+03x > With 6.0 branch: speed=1.43e+03x > With 5.1 branch: speed=2.92e+03x > > This is a significant decline from 5.1, getting slower with each > release... Is there anything that can be done about this? Would guess this is caused by overhead from tons of tiny frames. So 1) generate larger frames 2) use -filter_complex with no inputs instead of -f lavfi to eliminate all overhead from demuxing, decoding, and demux-decode/decode-filter inter-thread communication -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
On Wed, 6 Dec 2023, Anton Khirnov wrote: Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. In some cases the performance penalty because of threading is quite significant: Example command line: ffmpeg -f lavfi -i sine -af volume=6dB -f null none After latest threading changes: speed=810x Before latest threading changes: speed=1.13e+03x With 6.0 branch: speed=1.43e+03x With 5.1 branch: speed=2.92e+03x This is a significant decline from 5.1, getting slower with each release... Is there anything that can be done about this? 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] [ANNOUNCE] upcoming vote: TC/CC elections
On Wed, Dec 06, 2023 at 09:25:43AM +0100, Anton Khirnov wrote: > Quoting Niklas Haas (2023-12-05 12:01:48) > > On Tue, 05 Dec 2023 11:07:33 +0100 Anton Khirnov wrote: > > > Hi all, > > > Both elections have now concluded. > > > > > > We have 36 votes for the CC election (70% turnout) and 38 votes for TC > > > (75% turnout); raw votes in CSV format are attached. > > > > > > The CC members now are: > > > * James Almer > > > * Jean-Baptiste Kempf > > > * Anton Khirnov > > > * Ronald Bultje > > > * Michael Niedermayer > > > > > > For TC, it seems that we have a tie. The system reports two winning > > > sets, both of which contain: > > > * Michael Niedermayer > > > * Martin Storsjö > > > * Mark Thompson > > > * Anton Khirnov > > > > > > The final member is Jan Ekström in one set and Niklas Haas in the other. > > > We should now consider how to break this tie. Some options suggested on > > > IRC were: > > > * run a new vote with just the two of them > > > * randomly > > > * have Rémi break the tie, as he said he accidentally voted incorrectly > > > due to misinterpreting the documentation > > > * expand the committee > > > > Rather than run a new vote, I would prefer to give the spot to Jan. > > All the other alternatives have major issues, so I'd go with this as the > least bad option. It would be possible to add both Jan and Niklas to the alias but have only Jan vote. And if we end with a Tie on a vote have Niklas break the Tie thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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] avfilter/vf_libvmaf: fix string comparison bug
Hi,
On Mon, Dec 4, 2023 at 7:59 AM Nil Fons Miret via ffmpeg-devel
wrote:
>
> The libvmaf filter was doing substring checks in place of string
> equality comparisons. This led to a bug when the user specified the
> pooling method "harmonic_mean", since "mean" was checked first and the
> substring comparison returned true. This patch changes all substring
> comparisons for string equality comparisons. This is both correct and
> more efficient than the existing method.
>
> Signed-off-by: nilfm
> ---
> libavfilter/vf_libvmaf.c | 30 +++---
> 1 file changed, 15 insertions(+), 15 deletions(-)
>
> diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c
> index 12810b7267..46ff8154ef 100644
> --- a/libavfilter/vf_libvmaf.c
> +++ b/libavfilter/vf_libvmaf.c
> @@ -251,7 +251,7 @@ static int parse_features(AVFilterContext *ctx)
> const AVDictionaryEntry *e = NULL;
>
> while (e = av_dict_iterate(dict[i], e)) {
> -if (av_stristr(e->key, "name")) {
> +if (!strcmp(e->key, "name")) {
> feature_name = e->value;
> continue;
> }
> @@ -312,29 +312,29 @@ static int parse_models(AVFilterContext *ctx)
> char *path = NULL;
>
> while (e = av_dict_iterate(dict[i], e)) {
> -if (av_stristr(e->key, "disable_clip")) {
> -model_cfg.flags |= av_stristr(e->value, "true") ?
> +if (!strcmp(e->key, "disable_clip")) {
> +model_cfg.flags |= !strcmp(e->value, "true") ?
> VMAF_MODEL_FLAG_DISABLE_CLIP : 0;
> continue;
> }
>
> -if (av_stristr(e->key, "enable_transform")) {
> -model_cfg.flags |= av_stristr(e->value, "true") ?
> +if (!strcmp(e->key, "enable_transform")) {
> +model_cfg.flags |= !strcmp(e->value, "true") ?
> VMAF_MODEL_FLAG_ENABLE_TRANSFORM : 0;
> continue;
> }
>
> -if (av_stristr(e->key, "name")) {
> +if (!strcmp(e->key, "name")) {
> model_cfg.name = e->value;
> continue;
> }
>
> -if (av_stristr(e->key, "version")) {
> +if (!strcmp(e->key, "version")) {
> version = e->value;
> continue;
> }
>
> -if (av_stristr(e->key, "path")) {
> +if (!strcmp(e->key, "path")) {
> path = e->value;
> continue;
> }
> @@ -529,13 +529,13 @@ static int activate(AVFilterContext *ctx)
> static enum VmafOutputFormat log_fmt_map(const char *log_fmt)
> {
> if (log_fmt) {
> -if (av_stristr(log_fmt, "xml"))
> +if (!strcmp(log_fmt, "xml"))
> return VMAF_OUTPUT_FORMAT_XML;
> -if (av_stristr(log_fmt, "json"))
> +if (!strcmp(log_fmt, "json"))
> return VMAF_OUTPUT_FORMAT_JSON;
> -if (av_stristr(log_fmt, "csv"))
> +if (!strcmp(log_fmt, "csv"))
> return VMAF_OUTPUT_FORMAT_CSV;
> -if (av_stristr(log_fmt, "sub"))
> +if (!strcmp(log_fmt, "sub"))
> return VMAF_OUTPUT_FORMAT_SUB;
> }
>
> @@ -545,11 +545,11 @@ static enum VmafOutputFormat log_fmt_map(const
> char *log_fmt)
> static enum VmafPoolingMethod pool_method_map(const char *pool_method)
> {
> if (pool_method) {
> -if (av_stristr(pool_method, "min"))
> +if (!strcmp(pool_method, "min"))
> return VMAF_POOL_METHOD_MIN;
> -if (av_stristr(pool_method, "mean"))
> +if (!strcmp(pool_method, "mean"))
> return VMAF_POOL_METHOD_MEAN;
> -if (av_stristr(pool_method, "harmonic_mean"))
> +if (!strcmp(pool_method, "harmonic_mean"))
> return VMAF_POOL_METHOD_HARMONIC_MEAN;
> }
>
> --
> 2.37.1 (Apple Git-137.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".
Will push this tomorrow.
Thanks,
Kyle
___
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] avdevice/avfoundation: replace deprecated AVCaptureDevice
Am 06.12.23 um 13:03 schrieb xufuji456 via ffmpeg-devel:
Building with iOS platform, the compiler has a warning: "'devicesWithMediaType:' is
deprecated: first deprecated in iOS 10.0 - Use AVCaptureDeviceDiscoverySession
instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..5ebfe89dca 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,19 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) || (TARGET_OS_OSX
&& __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+[AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
deviceTypes should be an array of all possible types or we risk loosing
currently detected hardware.
Otherwise, LGTM.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi all, As usual when someone disagrees with him, Nicolas converged to being utterly unreasonable and deaf to all arguments. I see no point in discussing this with him any further and intend to push the set tomorrow, unless somebody else has substantial objections. I've considered asking for a TC vote, but as he is not suggesting any viable alternative, there is really nothing to vote on. So the purpose of this email is just summarizing the dispute, so others can understand it more easily. The issue concerns sub2video code, which allows converting bitmap subtitles to video streams, mainly for hardsubbing purposes. As subtitles are typically sparse in time, the demuxer that produces the subtitle stream emits "heartbeat" frames that are sent to the filtering code just like real subtitle frames. The code in ffmpeg_filter.c then decides whether these heartbeat frames should be sent to the filtergraph or ignored. The problem is that this decision is currently made in a way that depends on what frames previously arrived on _other_ filtergraph inputs (e.g. on video frames in a graph with a subtitle and a video input). However, the inputs are not synchronized, and the interleaving of frames on different inputs is effectively arbitrary. E.g. it depends on the video decoder delay (and thus on the number of frame threads, when frame threading is used). The reason this arbitrariness has not become a major issue until now, is that it is deterministic for a given run on a given machine (sub2video FATE tests do not use a frame-threaded decoder, and so do not exhibit the problem). With ffmpeg CLI becoming fully parallel, the results become non-deterministic and change from run to run, which forces me to do something about this. My solution in patch 01/10 changes the filtering code to always send the heartbeat frames to the filtergraph. This not only makes the results deterministic, but also improves subtitle timing in FATE tests. Nicolas presented a testcase that consists of taking a video+subtitle streams from a single source, offsetting them against each other by a fixed delay, and overlaying subtitle onto video. After my patch, this results in the filtergraph buffering a number of heartbeat frames proportional to the offset, which causes higher memory consumption. However, * the testcase suffers from the above problem - its output can change significantly depending on the number of decoder frame threads; this is fixed by my patch; * the extra buffering added by the patch is similar to what would be added by the muxer interleaving queue, were the streams remuxed rather than overlaid; * the buffering can be avoided entirely by opening the input twice. I thus consider his argument (that the patch is "breaking" the testcase) invalid, as the testcase is * contrived; * already broken; * actually fixed by my patch. Nicolas has also NOT suggested any viable alternative approach. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
> On Dec 6, 2023, at 02:44, Philip Langdale via ffmpeg-devel > wrote: > > On Sat, 2 Dec 2023 23:02:36 +0100 > Thomas Mundt wrote: > >> >> LGTM, thanks. >> > > I am going to squash the three commits and push. There's no real need > to put each filter in a separate diff when the logical change is > identical in all three. > Squashing sounds good to me. - 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".
Re: [FFmpeg-devel] [PATCH 06/25] fftools/ffmpeg_filter: configure buffersrc with csp/range
Quoting Niklas Haas (2023-11-09 13:19:38) > From: Niklas Haas > > Propagates input metadata to the input filter graph. > --- > fftools/ffmpeg_filter.c | 24 +--- > 1 file changed, 21 insertions(+), 3 deletions(-) Looks ok -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 05/25] avfilter/buffersrc: add color_space/range parameters
Quoting Niklas Haas (2023-11-09 13:19:37)
> @@ -328,6 +341,30 @@ static const AVOption buffer_options[] = {
> { "pixel_aspect", "sample aspect ratio",OFFSET(pixel_aspect),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> { "time_base", NULL, OFFSET(time_base),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> { "frame_rate",NULL, OFFSET(frame_rate),
> AV_OPT_TYPE_RATIONAL, { .dbl = 0 }, 0, DBL_MAX, V },
> +{ "colorspace", "select colorspace", OFFSET(color_space),
> AV_OPT_TYPE_INT, {.i64=AVCOL_SPC_UNSPECIFIED}, 0, AVCOL_SPC_NB-1, V,
> "colorspace"},
> +{ "gbr", NULL, 0, AV_OPT_TYPE_CONST, {.i64=AVCOL_SPC_RGB},
>INT_MIN, INT_MAX, V, "colorspace"},
^^^
is that intentional?
> @@ -432,6 +471,15 @@ static int query_formats(AVFilterContext *ctx)
> if ((ret = ff_add_format (&formats, c->pix_fmt)) < 0 ||
> (ret = ff_set_common_formats (ctx , formats )) < 0)
> return ret;
> +/* force specific colorspace/range downstream only for ordinary YUV
> */
> +if (ff_fmt_is_regular_yuv(c->pix_fmt)) {
What will this do when the colorspace is not set, as it will not be with
existing callers.
> diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
> index 3b248b37cd..4357a7bbfb 100644
> --- a/libavfilter/buffersrc.h
> +++ b/libavfilter/buffersrc.h
> @@ -105,6 +105,12 @@ typedef struct AVBufferSrcParameters {
> */
> AVBufferRef *hw_frames_ctx;
>
> +/**
> + * Video only, the YUV colorspace and range
> + */
> +enum AVColorSpace color_space;
> +enum AVColorRange color_range;
This has to go at the end of the struct, otherwise you're breaking ABI.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 03/25] avfilter: add negotiation API for color space/range
Quoting Niklas Haas (2023-11-09 13:19:35)
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 12383a28d3..ce3f90a674 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -2,6 +2,14 @@ The last version increases of all libraries were on
> 2023-02-09
>
> API changes, most recent first:
>
> +2023-11-xx - xx - lavf 58.14.100 - avfilter.h formats.h
> + Add AVFilterFormatsConfig.color_spaces, AVFilterFormatsConfig.color_ranges,
> + AVFilterLink.colorspace, AVFilterLink.color_range, ff_all_color_spaces,
> + ff_all_color_ranges, ff_set_common_color_spaces,
> ff_set_common_color_ranges,
> + ff_set_common_color_spaces_from_list, ff_set_common_color_ranges_from_list,
> + ff_set_common_all_color_spaces, ff_set_common_all_color_ranges,
> + ff_formats_check_color_spaces, ff_formats_check_color_ranges.
ff* are private and so shouldn't be mentioned in APIchanges
AVFilterFormatsConfig lives in a public header, but seems not to be
usable by API users.
> +
> 2023-11-08 - xx - lavu 58.32.100 - channel_layout.h
>Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
>Add AV_CH_LAYOUT_9POINT1POINT4_BACK and
> AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index ab7782862a..77bfec00c5 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -185,6 +185,7 @@ int avfilter_link(AVFilterContext *src, unsigned srcpad,
> link->type= src->output_pads[srcpad].type;
> av_assert0(AV_PIX_FMT_NONE == -1 && AV_SAMPLE_FMT_NONE == -1);
> link->format = -1;
> +link->colorspace = AVCOL_SPC_UNSPECIFIED;
> ff_framequeue_init(&link->fifo, &src->graph->internal->frame_queues);
>
> return 0;
> @@ -286,6 +287,12 @@ int avfilter_insert_filter(AVFilterLink *link,
> AVFilterContext *filt,
> if (link->outcfg.formats)
> ff_formats_changeref(&link->outcfg.formats,
>
> &filt->outputs[filt_dstpad_idx]->outcfg.formats);
> +if (link->outcfg.color_spaces)
> +ff_formats_changeref(&link->outcfg.color_spaces,
> +
> &filt->outputs[filt_dstpad_idx]->outcfg.color_spaces);
> +if (link->outcfg.color_ranges)
> +ff_formats_changeref(&link->outcfg.color_ranges,
> +
> &filt->outputs[filt_dstpad_idx]->outcfg.color_ranges);
> if (link->outcfg.samplerates)
> ff_formats_changeref(&link->outcfg.samplerates,
>
> &filt->outputs[filt_dstpad_idx]->outcfg.samplerates);
> @@ -730,6 +737,10 @@ static void free_link(AVFilterLink *link)
>
> ff_formats_unref(&link->incfg.formats);
> ff_formats_unref(&link->outcfg.formats);
> +ff_formats_unref(&link->incfg.color_spaces);
> +ff_formats_unref(&link->outcfg.color_spaces);
> +ff_formats_unref(&link->incfg.color_ranges);
> +ff_formats_unref(&link->outcfg.color_ranges);
> ff_formats_unref(&link->incfg.samplerates);
> ff_formats_unref(&link->outcfg.samplerates);
> ff_channel_layouts_unref(&link->incfg.channel_layouts);
> @@ -987,9 +998,11 @@ int ff_filter_frame(AVFilterLink *link, AVFrame *frame)
> strcmp(link->dst->filter->name, "idet") &&
> strcmp(link->dst->filter->name, "null") &&
> strcmp(link->dst->filter->name, "scale")) {
> -av_assert1(frame->format == link->format);
> -av_assert1(frame->width == link->w);
> -av_assert1(frame->height == link->h);
> +av_assert1(frame->format== link->format);
> +av_assert1(frame->width == link->w);
> +av_assert1(frame->height== link->h);
> +av_assert1(frame->colorspace== link->color_space);
^
Should not be there.
Also, these fail a LOT with this patch. Most of them seem fixed by later
patches, so it's probably better to move them to the end of the set?
> @@ -583,6 +602,29 @@ static enum AVSampleFormat
> find_best_sample_fmt_of_2(enum AVSampleFormat dst_fmt
> return score1 < score2 ? dst_fmt1 : dst_fmt2;
> }
>
> +int ff_fmt_is_regular_yuv(enum AVPixelFormat fmt)
> +{
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> +if (!desc)
> +return 0;
> +if (desc->nb_components < 3)
> +return 0; /* Grayscale is explicitly full-range in swscale */
> +if (desc->flags & (AV_PIX_FMT_FLAG_RGB | AV_PIX_FMT_FLAG_PAL |
> + AV_PIX_FMT_FLAG_XYZ | AV_PIX_FMT_FLAG_FLOAT))
Should this include AV_PIX_FMT_FLAG_HWACCEL too?
> +return 0;
> +
> +switch (fmt) {
> +case AV_PIX_FMT_YUVJ420P:
> +case AV_PIX_FMT_YUVJ422P:
> +case AV_PIX_FMT_YUVJ444P:
> +case AV_PIX_FMT_YUVJ440P:
> +case AV_PIX_FMT_YUVJ411P:
> +return 0;
> +default:
> +return 1;
> +}
> +}
> +
> static int pic
Re: [FFmpeg-devel] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
James Almer (12023-12-06): > I honestly can't believe you're arguing this. Yet I do, so I suggest you think a little harder to understand why I do. > And being condescending will not help your case. Can you tell that to Anton too please? > If i request -bitexact, i want bitexact output, regardless of running on a > core i3 or a Threadripper. There's nothing more to it. I had not noticed the -bitexact on the test command line. I will grant the change is acceptable if bit-exact is requested. > Calling random output that happens to be "acceptable" within the subjective > expectations of the user as useful sounds to me like you're trying to find > an excuse to keep buggy code with unpredictable results around, just because > it's been there for a long time. Well, you are wrong, and what I explained is the real reason: most subtitles are not timed that accurately. The subtitles on HBO's Last Week Tonight, for example, can randomly lag or be early by several seconds. Even serious subtitles, like the ones for scripted shows on Netflix/Amazon/Crunchyroll/whatever vary by a few tenths of seconds, i.e. several frames. And I have used this code. And I look carefully at subtitles. If the result was lower quality than the source material, I would have noticed and I would have endeavored to fix it. There never was need. Now, can Anton claim similar experience working with subtitles from the real world? Most of this discussions points to the answer being no. > So, like Anton has asked several times, suggest a way to keep deterministic > and bitexact output without exponentially increasing memory consumption due > to buffering. I will spend time and effort searching for a solution when we agree to work together. “Do this or I will break your code” is an unacceptable behavior, whether it is directed at me or at Paul or at anybody else, and I do not spend effort when unacceptable behavior is tolerated. -- Nicolas George ___ 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] avutil/mem: always align by at least 32 bytes
On Wed, 6 Dec 2023, Timo Rothenpieler wrote:
On 06/12/2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
Instead of now going through all instances of variables in structs
being declared as 32 byte aligned, this patch bumps the minimum alignment
to 32 bytes.
---
libavutil/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..26a9b9753b 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void free(void *ptr);
#endif /* MALLOC_PREFIX */
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_AVX512 ? 64 : 32)
LGTM
It could be good to add a comment here, to indicate how this value
relates to the alignemnts used in structs.
For others who commented in this thread, it all boils down to something
like this:
struct MyData {
uint8_t __attribute__((aligned(32))) aligned_data[1024];
};
It's even a bit more complex than that.
The case that's crashing right now is a member that has no alignment
declared on itself at all.
But another member of the same struct does, and so the compiler assumes
the whole struct to be aligned.
Ah, tricky! Yeah, that's also a valid assumption for the compiler, but
also a rather non-obvious one.
// 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] [PATCH] avutil/mem: always align by at least 32 bytes
On 06/12/2023 14:25, Martin Storsjö wrote:
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
Instead of now going through all instances of variables in structs
being declared as 32 byte aligned, this patch bumps the minimum alignment
to 32 bytes.
---
libavutil/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..26a9b9753b 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void free(void *ptr);
#endif /* MALLOC_PREFIX */
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_AVX512 ? 64 : 32)
LGTM
It could be good to add a comment here, to indicate how this value
relates to the alignemnts used in structs.
For others who commented in this thread, it all boils down to something
like this:
struct MyData {
uint8_t __attribute__((aligned(32))) aligned_data[1024];
};
It's even a bit more complex than that.
The case that's crashing right now is a member that has no alignment
declared on itself at all.
But another member of the same struct does, and so the compiler assumes
the whole struct to be aligned.
void func(void) {
struct MyData *obj = malloc(sizeof(*obj)); // Uusally only aligned
to 8 bytes
// operate on obj->aligned_data[]
}
Due to how aligned_data is declared, we promise to the compiler that it
is aligned to 32 bytes, and that the compiler can assume this wherever.
Depending on -march or whatever, this can be to access it with
instructions that assume 32 byte alignment.
// 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".
___
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] avutil/mem: always align by at least 32 bytes
On Sun, 3 Dec 2023, Timo Rothenpieler wrote:
FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs,
which then end up heap-allocated.
By declaring any variable in a struct, or tree of structs, to be 32 byte
aligned, it allows the compiler to safely assume the entire struct
itself is also 32 byte aligned.
This might make the compiler emit code which straight up crashes or
misbehaves in other ways, and at least in one instances is now
documented to actually do (see ticket 10549 on trac).
The issue there is that an unrelated variable in SingleChannelElement is
declared to have an alignment of 32 bytes. So if the compiler does a copy
in decode_cpe() with avx instructions, but ffmpeg is built with
--disable-avx, this results in a crash, since the memory is only 16 byte
aligned.
Mind you, even if the compiler does not emit avx instructions, the code
is still invalid and could misbehave. It just happens not to. Declaring
any variable in a struct with a 32 byte alignment promises 32 byte
alignment of the whole struct to the compiler.
Instead of now going through all instances of variables in structs
being declared as 32 byte aligned, this patch bumps the minimum alignment
to 32 bytes.
---
libavutil/mem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/mem.c b/libavutil/mem.c
index 36b8940a0c..26a9b9753b 100644
--- a/libavutil/mem.c
+++ b/libavutil/mem.c
@@ -62,7 +62,7 @@ void free(void *ptr);
#endif /* MALLOC_PREFIX */
-#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16))
+#define ALIGN (HAVE_AVX512 ? 64 : 32)
LGTM
It could be good to add a comment here, to indicate how this value relates
to the alignemnts used in structs.
For others who commented in this thread, it all boils down to something
like this:
struct MyData {
uint8_t __attribute__((aligned(32))) aligned_data[1024];
};
void func(void) {
struct MyData *obj = malloc(sizeof(*obj)); // Uusally only aligned to 8
bytes
// operate on obj->aligned_data[]
}
Due to how aligned_data is declared, we promise to the compiler that it is
aligned to 32 bytes, and that the compiler can assume this wherever.
Depending on -march or whatever, this can be to access it with
instructions that assume 32 byte alignment.
// 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] [PATCH 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
On 12/6/2023 9:55 AM, Nicolas George wrote: Anton Khirnov (12023-12-04): Which of these are you saying is correct? I do not know? Do you think I am able to reverse MD5 mentally? I am flattered, but I am sorry to confess I am not. Why do you not look at the resulting videos to judge for yourself? But I honestly can't believe you're arguing this. At this point you're just being defensive of your position without really taking into account what you were challenged with. to do that, you will need to remember (or learn two things): And being condescending will not help your case. First, most people do not have that many CPU threads available, and if they do they will spend them on encoding more than decoding. Second, and most important: for subtitles, in many many cases, a few frames of shift do not matter because the timing in the source material is not that accurate. So the answer to your question is: probably most of the ones generated with a sane number of threads are correct, in the sense that the result is within the acceptable accuracy of subtitles sync and useful for the user. How can you argue it's fine when you request bitexact output and do NOT get bitexact output? Go ahead and add that command line as a FATE test. See the runners turn yellow. Will you argue it's fine and not broken? Number of threads should not matter, the output has to be deterministic. Saying "Maybe the user likes what he gets. Varying amount of artifacts here and there or a few frames of shift here and there of difference between runs. It's fine!" is laughable. Of course, if the use case is one where perfect accuracy is necessary, users need to revert to a slower and more bulky procedure (like you suggested: open the file twice, which might require storing it entirely) to get it. So really, what you pretend is not breaking anything is really removing one of the options currently available to users in the compromise between speed, latency and accuracy. So I demand you stop pretending you are not breaking anything, stop pretending it is currently broken, just so you can move forward without bothering to search for a solution: that starts to feels like laziness and it always felt like rudeness because I spend a lot of effort in getting this to work in the cases where it can. The only bug that's been established to exist so far is in your heartbeat code, which produces random output as per above. As I explained many times, this is not a bug. If i request -bitexact, i want bitexact output, regardless of running on a core i3 or a Threadripper. There's nothing more to it. Buffering is by itself not a bug, otherwise you'd have to say the lavf interleaving queue is a bug. Once again, buffering thousands of frames and crashing because out of memory when the current code succeeds and produces an useful result is a regression and the patch series cannot be applied until that regression is fixed. Calling random output that happens to be "acceptable" within the subjective expectations of the user as useful sounds to me like you're trying to find an excuse to keep buggy code with unpredictable results around, just because it's been there for a long time. So for the last time - either suggest a specific and practical way of reducing memory consumption or stop interfering with my work. The specific and practical way is to let the current logic in place. There might be a few tweaks to make it more accurate, like looking into this comment: /* subtitles seem to be usually muxed ahead of other streams; if not, subtracting a larger time here is necessary */ pts2 = av_rescale_q(pts, tb, ifp->time_base) - 1; But first, we need you to stop behaving as if my previous efforts did not mater just because it does not overlap with your narrow use cases. Your previous efforts mattered, but evidently did not yield completely acceptable results, and this overhaul has exposed it. So, like Anton has asked several times, suggest a way to keep deterministic and bitexact output without exponentially increasing memory consumption due to buffering. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/avfilter: fix OOM case for default activate
Paul B Mahol (12023-12-01): > From 2ea2a0df61cbd5519a1c1e88be27a3f8eb883aac Mon Sep 17 00:00:00 2001 > From: Paul B Mahol > Date: Fri, 1 Dec 2023 16:59:07 +0100 > Subject: [PATCH] avfilter/avfilter: fix OOM case for default activate > > Fixes OOM when caller keeps adding frames into filtergraph > that reached EOF by other means, for example EOF is signalled > by other filter in filtergraph or by buffersink. > > Signed-off-by: Paul B Mahol > --- > libavfilter/avfilter.c | 10 ++ > 1 file changed, 10 insertions(+) Looks correct. Good catch. I am assuming it is enough to fix the issue you wanted to fix by turning buffersrc to activate. If not, please share the test case you use. -- Nicolas George ___ 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] lavc/qsvenc: Set default bitrate to 2M
> On Dec 6, 2023, at 20:26, Timo Rothenpieler wrote:
>
> On 06/12/2023 07:51, Xiang, Haihao wrote:
>> On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
>>> On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c | 2 +-
libavcodec/qsvenc_hevc.c | 2 +-
libavcodec/qsvenc_mpeg2.c | 2 +-
libavcodec/qsvenc_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
index c697845d7b..78c92c1844 100644
--- a/libavcodec/qsvenc_av1.c
+++ b/libavcodec/qsvenc_av1.c
@@ -129,7 +129,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M" },
+{ "b", "2M" },
>>>
>>> Wouldn't it be better to use a constant quality option as default,
>>> rather than a fixed bitrate?
>> Did you mean change the default bitrate control mode to CQP ? I was concerned
>> about the impact to current users.
>
> Yeah, it's technically a breaking change.
> Though at least libx264 also at some point changed its default to a
> reasonable medium quality crf mode, away from a fixed, rather low, bitrate.
> Not sure if that was done on a major bump, or if it was considered low impact
> enough to just push out.
>
>>> 2M still seems incredibly low for 1080p, let alone for 4K content.
>> Some other HW encoders also use 2M, I'd like to use the same default value.
>
> It's probably worth considering switching those to a crf equivalent as well,
> where possible.
> It matches much more what a typical user would expect if they input a
> commandline with no further options.
Without a strategy to adapt to different needs automatically like crf, I prefer
error out than
a default bitrate TBH. Of course we cannot do that now since it will suddenly
break current
use cases. How about set default bitrate to zero, then add a warning message if
user don’t
change it, then set bitrate to any default/heuristics value?
>
>> Thanks
>> Haihao
>>>
{ "g", "-1" },
{ "bf","-1" },
{ "refs", "0"},
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 071a9a79e9..37b39cb441 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -178,7 +178,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "-1"},
{ "bf","-1"},
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index c5b7ac7cc4..181d06cb00 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -374,7 +374,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "248" },
{ "bf","-1"},
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index 22f1ff7c0d..012cec3a58 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -82,7 +82,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
// same as the x264 default
{ "g", "250" },
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index d0340ef94b..8658b8ec2d 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -93,7 +93,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
-{ "b", "1M"},
+{ "b", "2M"},
{ "refs", "0" },
{ "g", "250" },
{ "trellis", "-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 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.or
Re: [FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > After weeks of discussion, you have NOT suggested any workable > alternative. Indeed. And the reason for that is that all the time I have available on this is spent debunking your libel about the current logic. > Producing unpredictable output generally means broken. > And "my feature produces random data, but needs very little memory for > it" is not a valid argument. In this particular case you are absolutely wrong, probably because of a lack of familiarity with the use of subtitles in the real world. See the explanations in the mail I just sent. -- Nicolas George ___ 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] avutil/mem: always align by at least 32 bytes
On 06/12/2023 13:31, James Almer wrote: On 12/3/2023 5:10 PM, Timo Rothenpieler wrote: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Wont we run into similar issues with avx512 eventually? It's only indirectly related to AVX. The core issue is that we have structs with elements that declare an alignment of 32 bytes all over the codebase. I checked all instances, and we do not have any struct members that declare a higher alignment requirement than 32. (There's two instances of 64 byte alignment, but those are not on struct members, but on stack variables.) This promises the compiler that the memory of the whole struct is aligned accordingly. So no matter if it breaks because of AVX or something else, the compiler could generate broken code if we heap allocate those structs with too small of an alignment. It could generate other, non-AVX code, that depends on that alignment. So we will only run into this again if someone decides to add a struct member with bigger alignment to a heap allocated struct somewhere. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as ___ 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 13/13 v3] fftools/ffmpeg: convert to a threaded architecture
Anton Khirnov (12023-12-04): > Which of these are you saying is correct? I do not know? Do you think I am able to reverse MD5 mentally? I am flattered, but I am sorry to confess I am not. Why do you not look at the resulting videos to judge for yourself? But to do that, you will need to remember (or learn two things): First, most people do not have that many CPU threads available, and if they do they will spend them on encoding more than decoding. Second, and most important: for subtitles, in many many cases, a few frames of shift do not matter because the timing in the source material is not that accurate. So the answer to your question is: probably most of the ones generated with a sane number of threads are correct, in the sense that the result is within the acceptable accuracy of subtitles sync and useful for the user. Of course, if the use case is one where perfect accuracy is necessary, users need to revert to a slower and more bulky procedure (like you suggested: open the file twice, which might require storing it entirely) to get it. So really, what you pretend is not breaking anything is really removing one of the options currently available to users in the compromise between speed, latency and accuracy. So I demand you stop pretending you are not breaking anything, stop pretending it is currently broken, just so you can move forward without bothering to search for a solution: that starts to feels like laziness and it always felt like rudeness because I spend a lot of effort in getting this to work in the cases where it can. > The only bug that's been established to exist so far is in your > heartbeat code, which produces random output as per above. As I explained many times, this is not a bug. > Buffering is by itself not a bug, otherwise you'd have to say the lavf > interleaving queue is a bug. Once again, buffering thousands of frames and crashing because out of memory when the current code succeeds and produces an useful result is a regression and the patch series cannot be applied until that regression is fixed. > So for the last time - either suggest a specific and practical way of > reducing memory consumption or stop interfering with my work. The specific and practical way is to let the current logic in place. There might be a few tweaks to make it more accurate, like looking into this comment: /* subtitles seem to be usually muxed ahead of other streams; if not, subtracting a larger time here is necessary */ pts2 = av_rescale_q(pts, tb, ifp->time_base) - 1; But first, we need you to stop behaving as if my previous efforts did not mater just because it does not overlap with your narrow use cases. -- Nicolas George ___ 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] avutil/mem: always align by at least 32 bytes
On 12/6/2023 9:50 AM, Ronald S. Bultje wrote: Hi, On Sun, Dec 3, 2023 at 3:10 PM Timo Rothenpieler wrote: So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx Ehm... What? That seems like the core bug then? --disable-avx will disable any ffmpeg specific AVX dsp function that depends on HAVE_AVX_EXTERNAL and similar, but will not do anything to the -march argument you can pass the compiler with the --cpu configure option. configure --cpu=haswell --disable-avx is completely valid. 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". ___ 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] avutil/mem: always align by at least 32 bytes
Hi, On Sun, Dec 3, 2023 at 3:10 PM Timo Rothenpieler wrote: > So if the compiler does a copy > in decode_cpe() with avx instructions, but ffmpeg is built with > --disable-avx > Ehm... What? That seems like the core bug then? 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] [PATCH] avutil/mem: always align by at least 32 bytes
On 12/3/2023 5:10 PM, Timo Rothenpieler wrote: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Wont we run into similar issues with avx512 eventually? Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as ___ 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
Quoting Nicolas George (2023-12-06 13:10:41) > I have offered Anton my help. After weeks of discussion, you have NOT suggested any workable alternative. The single suggestion I did see from you * was already implemented * did not address the issues at all > But first he needs to acknowledge there he is breaking something > instead of pretending it was already broken Producing unpredictable output generally means broken. And "my feature produces random data, but needs very little memory for it" is not a valid argument. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/mem: always align by at least 32 bytes
On 03/12/2023 21:10, Timo Rothenpieler wrote: FFmpeg has instances of DECLARE_ALIGNED(32, ...) in a lot of structs, which then end up heap-allocated. By declaring any variable in a struct, or tree of structs, to be 32 byte aligned, it allows the compiler to safely assume the entire struct itself is also 32 byte aligned. This might make the compiler emit code which straight up crashes or misbehaves in other ways, and at least in one instances is now documented to actually do (see ticket 10549 on trac). The issue there is that an unrelated variable in SingleChannelElement is declared to have an alignment of 32 bytes. So if the compiler does a copy in decode_cpe() with avx instructions, but ffmpeg is built with --disable-avx, this results in a crash, since the memory is only 16 byte aligned. Mind you, even if the compiler does not emit avx instructions, the code is still invalid and could misbehave. It just happens not to. Declaring any variable in a struct with a 32 byte alignment promises 32 byte alignment of the whole struct to the compiler. Instead of now going through all instances of variables in structs being declared as 32 byte aligned, this patch bumps the minimum alignment to 32 bytes. --- libavutil/mem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavutil/mem.c b/libavutil/mem.c index 36b8940a0c..26a9b9753b 100644 --- a/libavutil/mem.c +++ b/libavutil/mem.c @@ -62,7 +62,7 @@ void free(void *ptr); #endif /* MALLOC_PREFIX */ -#define ALIGN (HAVE_AVX512 ? 64 : (HAVE_AVX ? 32 : 16)) +#define ALIGN (HAVE_AVX512 ? 64 : 32) /* NOTE: if you want to override these functions with your own * implementations (not recommended) you have to link libav* as 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] lavc/qsvenc: Set default bitrate to 2M
On 06/12/2023 07:51, Xiang, Haihao wrote:
On Di, 2023-12-05 at 12:47 +0100, Timo Rothenpieler wrote:
On 05.12.2023 09:15, Xiang, Haihao wrote:
From: Haihao Xiang
2M is suitable for more cases, e.g. 4K video.
Signed-off-by: Haihao Xiang
---
libavcodec/qsvenc_av1.c | 2 +-
libavcodec/qsvenc_h264.c | 2 +-
libavcodec/qsvenc_hevc.c | 2 +-
libavcodec/qsvenc_mpeg2.c | 2 +-
libavcodec/qsvenc_vp9.c | 2 +-
5 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/qsvenc_av1.c b/libavcodec/qsvenc_av1.c
index c697845d7b..78c92c1844 100644
--- a/libavcodec/qsvenc_av1.c
+++ b/libavcodec/qsvenc_av1.c
@@ -129,7 +129,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
Wouldn't it be better to use a constant quality option as default,
rather than a fixed bitrate?
Did you mean change the default bitrate control mode to CQP ? I was concerned
about the impact to current users.
Yeah, it's technically a breaking change.
Though at least libx264 also at some point changed its default to a
reasonable medium quality crf mode, away from a fixed, rather low, bitrate.
Not sure if that was done on a major bump, or if it was considered low
impact enough to just push out.
2M still seems incredibly low for 1080p, let alone for 4K content.
Some other HW encoders also use 2M, I'd like to use the same default value.
It's probably worth considering switching those to a crf equivalent as
well, where possible.
It matches much more what a typical user would expect if they input a
commandline with no further options.
Thanks
Haihao
{ "g", "-1" },
{ "bf", "-1" },
{ "refs", "0" },
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 071a9a79e9..37b39cb441 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -178,7 +178,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "-1" },
{ "bf", "-1" },
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index c5b7ac7cc4..181d06cb00 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -374,7 +374,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "248" },
{ "bf", "-1" },
diff --git a/libavcodec/qsvenc_mpeg2.c b/libavcodec/qsvenc_mpeg2.c
index 22f1ff7c0d..012cec3a58 100644
--- a/libavcodec/qsvenc_mpeg2.c
+++ b/libavcodec/qsvenc_mpeg2.c
@@ -82,7 +82,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
// same as the x264 default
{ "g", "250" },
diff --git a/libavcodec/qsvenc_vp9.c b/libavcodec/qsvenc_vp9.c
index d0340ef94b..8658b8ec2d 100644
--- a/libavcodec/qsvenc_vp9.c
+++ b/libavcodec/qsvenc_vp9.c
@@ -93,7 +93,7 @@ static const AVClass class = {
};
static const FFCodecDefault qsv_enc_defaults[] = {
- { "b", "1M" },
+ { "b", "2M" },
{ "refs", "0" },
{ "g", "250" },
{ "trellis", "-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 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 v3] ffmpeg CLI multithreading
Zhao Zhili (12023-12-06): > For such large patch set, it’s almost impossible to not break any corner case. Yes, that is what review is for. > Considering the improvements the patch set brings into fftools, those corner > cases can be fixed after merge. That means never. No. > And any body can try to figure out a proper fix after merged, rather than > blocking > the patch set and let Anton work on it alone. I have offered Anton my help. But first he needs to acknowledge there he is breaking something instead of pretending it was already broken so that he can ignore the issue entirely and move on with the parts of the code that matter to himself. -- Nicolas George ___ 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
> On Dec 6, 2023, at 18:55, Nicolas George wrote: > > Anton Khirnov (12023-12-06): >> this should hopefully be the last version of this set. If nobody has new >> comments, I will push it in a few days. > > Absolutely not: you cannot push until consensus is reached, and > consensus is not reached since you are still breaking the sparseness of > sub2video frame. I will answer the last mail in the ongoing discussion > soon. For such large patch set, it’s almost impossible to not break any corner case. Considering the improvements the patch set brings into fftools, those corner cases can be fixed after merge. And any body can try to figure out a proper fix after merged, rather than blocking the patch set and let Anton work on it alone. I want to discuss how to deal with libavdevice/SDL2 issue after applying the patch set, not before. > > -- > Nicolas George > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avdevice/avfoundation: replace deprecated AVCaptureDevice
Building with iOS platform, the compiler has a warning:
"'devicesWithMediaType:' is deprecated: first deprecated in iOS 10.0 - Use
AVCaptureDeviceDiscoverySession instead"
Signed-off-by: xufuji456 <839789...@qq.com>
---
libavdevice/avfoundation.m | 23 ++-
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 36ad834753..5ebfe89dca 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -761,6 +761,19 @@ static int get_audio_config(AVFormatContext *s)
return 0;
}
+static NSArray* getDevicesWithMediaType(AVMediaType mediaType) {
+#if ((TARGET_OS_IPHONE && __IPHONE_OS_VERSION_MAX_ALLOWED >= 10) ||
(TARGET_OS_OSX && __MAC_OS_X_VERSION_MAX_ALLOWED >= 101500))
+AVCaptureDeviceDiscoverySession *captureDeviceDiscoverySession =
+[AVCaptureDeviceDiscoverySession
+
discoverySessionWithDeviceTypes:@[AVCaptureDeviceTypeBuiltInWideAngleCamera]
+ mediaType:mediaType
+ position:AVCaptureDevicePositionUnspecified];
+return [captureDeviceDiscoverySession devices];
+#else
+return [AVCaptureDevice devicesWithMediaType:mediaType];
+#endif
+}
+
static int avf_read_header(AVFormatContext *s)
{
int ret = 0;
@@ -770,8 +783,8 @@ static int avf_read_header(AVFormatContext *s)
AVCaptureDevice *video_device = nil;
AVCaptureDevice *audio_device = nil;
// Find capture device
-NSArray *devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeVideo];
-NSArray *devices_muxed = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeMuxed];
+NSArray *devices = getDevicesWithMediaType(AVMediaTypeVideo);
+NSArray *devices_muxed = getDevicesWithMediaType(AVMediaTypeMuxed);
ctx->num_video_devices = [devices count] + [devices_muxed count];
@@ -806,7 +819,7 @@ static int avf_read_header(AVFormatContext *s)
#endif
av_log(ctx, AV_LOG_INFO, "AVFoundation audio devices:\n");
-devices = [AVCaptureDevice devicesWithMediaType:AVMediaTypeAudio];
+devices = getDevicesWithMediaType(AVMediaTypeAudio);
for (AVCaptureDevice *device in devices) {
const char *name = [[device localizedName] UTF8String];
int index = [devices indexOfObject:device];
@@ -930,7 +943,7 @@ static int avf_read_header(AVFormatContext *s)
// get audio device
if (ctx->audio_device_index >= 0) {
-NSArray *devices = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeAudio];
+NSArray *devices = getDevicesWithMediaType(AVMediaTypeAudio);
if (ctx->audio_device_index >= [devices count]) {
av_log(ctx, AV_LOG_ERROR, "Invalid audio device index\n");
@@ -943,7 +956,7 @@ static int avf_read_header(AVFormatContext *s)
if (!strncmp(ctx->audio_filename, "default", 7)) {
audio_device = [AVCaptureDevice
defaultDeviceWithMediaType:AVMediaTypeAudio];
} else {
-NSArray *devices = [AVCaptureDevice
devicesWithMediaType:AVMediaTypeAudio];
+NSArray *devices = getDevicesWithMediaType(AVMediaTypeAudio);
for (AVCaptureDevice *device in devices) {
if (!strncmp(ctx->audio_filename, [[device localizedName]
UTF8String], strlen(ctx->audio_filename))) {
--
2.32.0 (Apple Git-132)
___
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 10/10] fftools/ffmpeg: convert to a threaded architecture
Quoting Paul B Mahol (2023-12-06 12:22:48) > On Wed, Dec 6, 2023 at 11:32 AM Anton Khirnov wrote: > > > Change the main loop and every component (demuxers, decoders, filters, > > encoders, muxers) to use the previously added transcode scheduler. Every > > instance of every such component was already running in a separate > > thread, but now they can actually run in parallel. > > > > Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by > > JEEB to be more correct and deterministic. > > > > Un-reviewable, please split it. Here https://git.khirnov.net/libav.git/log/?h=ffmpeg_threading_split -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] tests/fate: add median filter test
Attached. From 2c54553b83f2b67f781c67cb72deb4a5f267a8f1 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Wed, 6 Dec 2023 12:17:54 +0100 Subject: [PATCH] tests/fate: add median filter test Signed-off-by: Paul B Mahol --- tests/fate/filter-video.mak | 3 +++ tests/ref/fate/filter-median | 1 + 2 files changed, 4 insertions(+) create mode 100644 tests/ref/fate/filter-median diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index 4defaf5877..b57ef88c9b 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -456,6 +456,9 @@ FATE_FILTER_VSYNTH_VIDEO_FILTER-$(call ALLYES, SCALE_FILTER FORMAT_FILTER PERMS_ fate-filter-edgedetect: CMD = video_filter "scale,format=gray,perms=random,edgedetect" -frames:v 20 fate-filter-edgedetect-colormix: CMD = video_filter "scale,format=gbrp,perms=random,edgedetect=mode=colormix" -frames:v 20 +FATE_FILTER_VSYNTH_VIDEO_FILTER-$(CONFIG_MEDIAN_FILTER) += fate-filter-median +fate-filter-median: CMD = video_filter "median=radius=5" + FATE_FILTER_VSYNTH_VIDEO_FILTER-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue1 fate-filter-hue2 fate-filter-hue3 fate-filter-hue1: CMD = video_filter "perms=random,hue=s=sin(2*PI*t)+1" -frames:v 20 fate-filter-hue2: CMD = video_filter "perms=random,hue=h=18*n" -frames:v 20 diff --git a/tests/ref/fate/filter-median b/tests/ref/fate/filter-median new file mode 100644 index 00..22dfaba576 --- /dev/null +++ b/tests/ref/fate/filter-median @@ -0,0 +1 @@ +median 8754a3715917ff8b20ff520c4bb4370c -- 2.42.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 v3] ffmpeg CLI multithreading
Anton Khirnov (12023-12-06): > this should hopefully be the last version of this set. If nobody has new > comments, I will push it in a few days. Absolutely not: you cannot push until consensus is reached, and consensus is not reached since you are still breaking the sparseness of sub2video frame. I will answer the last mail in the ongoing discussion soon. -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] web: add a news entry for ffmpeg CLI threading
--- src/index | 14 ++ 1 file changed, 14 insertions(+) diff --git a/src/index b/src/index index 0d68db5..22f6844 100644 --- a/src/index +++ b/src/index @@ -35,6 +35,20 @@ News + December xxth, 2023, multi-threaded ffmpeg CLI tool + + Thanks to a major refactoring of the ffmpeg command-line tool, all the major + components of the transcoding pipeline (demuxers, decoders, filters, encodes, muxers) now + run in parallel. This should improve throughput and CPU utilization, decrease latency, + and open the way to other exciting new features. + + + + Note that you should not expect significant performance improvements in cases + where almost all computational time is spent in a single component (typically video + encoding). + + November 10th, 2023, FFmpeg 6.1 "Heaviside" FFmpeg 6.1 "Heaviside", a new -- 2.42.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] avfilter/vf_bwdif: consider chroma subsampling when enforcing minimum dimensions
On Sat, 2 Dec 2023 23:02:36 +0100 Thomas Mundt wrote: > > LGTM, thanks. > I am going to squash the three commits and push. There's no real need to put each filter in a separate diff when the logical change is identical in all three. Thanks, --phil ___ 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 10/10] fftools/ffmpeg: convert to a threaded architecture
Change the main loop and every component (demuxers, decoders, filters,
encoders, muxers) to use the previously added transcode scheduler. Every
instance of every such component was already running in a separate
thread, but now they can actually run in parallel.
Changes the results of ffmpeg-fix_sub_duration_heartbeat - tested by
JEEB to be more correct and deterministic.
---
Changelog | 2 +
fftools/ffmpeg.c | 374 +
fftools/ffmpeg.h | 97 +--
fftools/ffmpeg_dec.c | 321 ++--
fftools/ffmpeg_demux.c| 268 ---
fftools/ffmpeg_enc.c | 368 ++---
fftools/ffmpeg_filter.c | 722 +-
fftools/ffmpeg_mux.c | 324 ++--
fftools/ffmpeg_mux.h | 24 +-
fftools/ffmpeg_mux_init.c | 88 +--
fftools/ffmpeg_opt.c | 6 +-
.../fate/ffmpeg-fix_sub_duration_heartbeat| 36 +-
12 files changed, 600 insertions(+), 2030 deletions(-)
diff --git a/Changelog b/Changelog
index f00bc27ca4..67ef92eb02 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,8 @@ version :
- EVC encoding using external library libxeve
- QOA decoder and demuxer
- aap filter
+- demuxing, decoding, filtering, encoding, and muxing in the
+ ffmpeg CLI now all run in parallel
version 6.1:
- libaribcaption decoder
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index b8a97258a0..30b594fd97 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -117,7 +117,7 @@ typedef struct BenchmarkTimeStamps {
static BenchmarkTimeStamps get_benchmark_time_stamps(void);
static int64_t getmaxrss(void);
-unsigned nb_output_dumped = 0;
+atomic_uint nb_output_dumped = 0;
static BenchmarkTimeStamps current_time;
AVIOContext *progress_avio = NULL;
@@ -138,30 +138,6 @@ static struct termios oldtty;
static int restore_tty;
#endif
-/* sub2video hack:
- Convert subtitles to video with alpha to insert them in filter graphs.
- This is a temporary solution until libavfilter gets real subtitles support.
- */
-
-static void sub2video_heartbeat(InputFile *infile, int64_t pts, AVRational tb)
-{
-/* When a frame is read from a file, examine all sub2video streams in
- the same file and send the sub2video frame again. Otherwise, decoded
- video frames could be accumulating in the filter graph while a filter
- (possibly overlay) is desperately waiting for a subtitle frame. */
-for (int i = 0; i < infile->nb_streams; i++) {
-InputStream *ist = infile->streams[i];
-
-if (ist->dec_ctx->codec_type != AVMEDIA_TYPE_SUBTITLE)
-continue;
-
-for (int j = 0; j < ist->nb_filters; j++)
-ifilter_sub2video_heartbeat(ist->filters[j], pts, tb);
-}
-}
-
-/* end of sub2video hack */
-
static void term_exit_sigsafe(void)
{
#if HAVE_TERMIOS_H
@@ -499,23 +475,13 @@ void update_benchmark(const char *fmt, ...)
}
}
-void close_output_stream(OutputStream *ost)
-{
-OutputFile *of = output_files[ost->file_index];
-ost->finished |= ENCODER_FINISHED;
-
-if (ost->sq_idx_encode >= 0)
-sq_send(of->sq_encode, ost->sq_idx_encode, SQFRAME(NULL));
-}
-
-static void print_report(int is_last_report, int64_t timer_start, int64_t
cur_time)
+static void print_report(int is_last_report, int64_t timer_start, int64_t
cur_time, int64_t pts)
{
AVBPrint buf, buf_script;
int64_t total_size = of_filesize(output_files[0]);
int vid;
double bitrate;
double speed;
-int64_t pts = AV_NOPTS_VALUE;
static int64_t last_time = -1;
static int first_report = 1;
uint64_t nb_frames_dup = 0, nb_frames_drop = 0;
@@ -533,7 +499,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
last_time = cur_time;
}
if (((cur_time - last_time) < stats_period && !first_report) ||
-(first_report && nb_output_dumped < nb_output_files))
+(first_report && atomic_load(&nb_output_dumped) < nb_output_files))
return;
last_time = cur_time;
}
@@ -544,7 +510,7 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(&buf_script, 0, AV_BPRINT_SIZE_AUTOMATIC);
for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost)) {
-const float q = ost->enc ? ost->quality / (float) FF_QP2LAMBDA : -1;
+const float q = ost->enc ? atomic_load(&ost->quality) / (float)
FF_QP2LAMBDA : -1;
if (vid && ost->type == AVMEDIA_TYPE_VIDEO) {
av_bprintf(&buf, "q=%2.1f ", q);
@@ -565,22 +531,18 @@ static void print_report(int is_last_report, int64_t
timer_start, int64_t cur_ti
if (is_last_report)
av_bprintf(&buf, "
[FFmpeg-devel] [PATCH 09/10] fftools/ffmpeg: add thread-aware transcode scheduling infrastructure
See the comment block at the top of fftools/ffmpeg_sched.h for more
details on what this scheduler is for.
This commit adds the scheduling code itself, along with minimal
integration with the rest of the program:
* allocating and freeing the scheduler
* passing it throughout the call stack in order to register the
individual components (demuxers/decoders/filtergraphs/encoders/muxers)
with the scheduler
The scheduler is not actually used as of this commit, so it should not
result in any change in behavior. That will change in future commits.
---
fftools/Makefile |1 +
fftools/ffmpeg.c | 18 +-
fftools/ffmpeg.h | 24 +-
fftools/ffmpeg_dec.c | 10 +-
fftools/ffmpeg_demux.c| 46 +-
fftools/ffmpeg_enc.c | 13 +-
fftools/ffmpeg_filter.c | 37 +-
fftools/ffmpeg_mux.c | 17 +-
fftools/ffmpeg_mux.h | 12 +
fftools/ffmpeg_mux_init.c | 106 +-
fftools/ffmpeg_opt.c | 22 +-
fftools/ffmpeg_sched.c| 2172 +
fftools/ffmpeg_sched.h| 468
13 files changed, 2890 insertions(+), 56 deletions(-)
create mode 100644 fftools/ffmpeg_sched.c
create mode 100644 fftools/ffmpeg_sched.h
diff --git a/fftools/Makefile b/fftools/Makefile
index 3c763e3db9..083a1368ce 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -18,6 +18,7 @@ OBJS-ffmpeg += \
fftools/ffmpeg_mux.o\
fftools/ffmpeg_mux_init.o \
fftools/ffmpeg_opt.o\
+fftools/ffmpeg_sched.o \
fftools/objpool.o \
fftools/sync_queue.o\
fftools/thread_queue.o \
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index cf8a50bffc..b8a97258a0 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -99,6 +99,7 @@
#include "cmdutils.h"
#include "ffmpeg.h"
+#include "ffmpeg_sched.h"
#include "ffmpeg_utils.h"
#include "sync_queue.h"
@@ -1167,7 +1168,7 @@ static int transcode_step(OutputStream *ost, AVPacket
*demux_pkt)
/*
* The following code is the main loop of the file converter
*/
-static int transcode(int *err_rate_exceeded)
+static int transcode(Scheduler *sch, int *err_rate_exceeded)
{
int ret = 0, i;
InputStream *ist;
@@ -1305,6 +1306,8 @@ static int64_t getmaxrss(void)
int main(int argc, char **argv)
{
+Scheduler *sch = NULL;
+
int ret, err_rate_exceeded;
BenchmarkTimeStamps ti;
@@ -1322,8 +1325,14 @@ int main(int argc, char **argv)
show_banner(argc, argv, options);
+sch = sch_alloc();
+if (!sch) {
+ret = AVERROR(ENOMEM);
+goto finish;
+}
+
/* parse options and open all input/output files */
-ret = ffmpeg_parse_options(argc, argv);
+ret = ffmpeg_parse_options(argc, argv, sch);
if (ret < 0)
goto finish;
@@ -1341,7 +1350,7 @@ int main(int argc, char **argv)
}
current_time = ti = get_benchmark_time_stamps();
-ret = transcode(&err_rate_exceeded);
+ret = transcode(sch, &err_rate_exceeded);
if (ret >= 0 && do_benchmark) {
int64_t utime, stime, rtime;
current_time = get_benchmark_time_stamps();
@@ -1361,5 +1370,8 @@ finish:
ret = 0;
ffmpeg_cleanup(ret);
+
+sch_free(&sch);
+
return ret;
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 3c153021f8..a89038b765 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -27,6 +27,7 @@
#include
#include "cmdutils.h"
+#include "ffmpeg_sched.h"
#include "sync_queue.h"
#include "libavformat/avformat.h"
@@ -721,7 +722,8 @@ int parse_and_set_vsync(const char *arg, int *vsync_var,
int file_idx, int st_id
int check_filter_outputs(void);
int filtergraph_is_simple(const FilterGraph *fg);
int init_simple_filtergraph(InputStream *ist, OutputStream *ost,
-char *graph_desc);
+char *graph_desc,
+Scheduler *sch, unsigned sch_idx_enc);
int init_complex_filtergraph(FilterGraph *fg);
int copy_av_subtitle(AVSubtitle *dst, const AVSubtitle *src);
@@ -746,7 +748,8 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational t
*/
int ifilter_parameters_from_dec(InputFilter *ifilter, const AVCodecContext
*dec);
-int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost);
+int ofilter_bind_ost(OutputFilter *ofilter, OutputStream *ost,
+ unsigned sched_idx_enc);
/**
* Create a new filtergraph in the global filtergraph list.
@@ -754,7 +757,7 @@ int ofilter_bind_ost(OutputFilter *ofilter, OutputStream
*ost);
* @param graph_desc Graph description; an av_malloc()ed string, filtergraph
* takes ownership of it.
*/
-int fg_create(FilterGraph **pfg, char *graph_desc);
+int fg_create(FilterGraph **pfg, char *graph_desc, Scheduler *sch);
void fg_free(FilterGraph **pfg);
@@ -778,7 +781,7 @@ void fg_send_command(FilterGraph *fg, double time, const
char *target,
*/
int reap_filter
[FFmpeg-devel] [PATCH 08/10] fftools/ffmpeg_enc: move encoding to a separate thread
As for the analogous decoding change, this is only a preparatory step to
a fully threaded architecture and does not yet make encoding truly
parallel. The main thread will currently submit a frame and wait until
it has been fully processed by the encoder before moving on. That will
change in future commits after filters are moved to threads and a
thread-aware scheduler is added.
This code suffers from a known issue - if an encoder with a sync queue
receives EOF it will terminate after processing everything it currently
has, even though the sync queue might still be triggered by other
threads. That will be fixed in following commits.
---
fftools/ffmpeg_enc.c | 360 ++-
1 file changed, 320 insertions(+), 40 deletions(-)
diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index fa4539664f..46c21fc0e4 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -20,6 +20,8 @@
#include
#include "ffmpeg.h"
+#include "ffmpeg_utils.h"
+#include "thread_queue.h"
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
@@ -43,6 +45,7 @@ struct Encoder {
// packet for receiving encoded output
AVPacket *pkt;
+AVFrame *sub_frame;
// combined size of all the packets received from the encoder
uint64_t data_size;
@@ -51,8 +54,48 @@ struct Encoder {
uint64_t packets_encoded;
int opened;
+int finished;
+
+pthread_t thread;
+/**
+ * Queue for sending frames from the main thread to
+ * the encoder thread.
+ */
+ThreadQueue*queue_in;
+/**
+ * Queue for sending encoded packets from the encoder thread
+ * to the main thread.
+ *
+ * An empty packet is sent to signal that a previously sent
+ * frame has been fully processed.
+ */
+ThreadQueue*queue_out;
};
+// data that is local to the decoder thread and not visible outside of it
+typedef struct EncoderThread {
+AVFrame *frame;
+AVPacket *pkt;
+} EncoderThread;
+
+static int enc_thread_stop(Encoder *e)
+{
+void *ret;
+
+if (!e->queue_in)
+return 0;
+
+tq_send_finish(e->queue_in, 0);
+tq_receive_finish(e->queue_out, 0);
+
+pthread_join(e->thread, &ret);
+
+tq_free(&e->queue_in);
+tq_free(&e->queue_out);
+
+return (int)(intptr_t)ret;
+}
+
void enc_free(Encoder **penc)
{
Encoder *enc = *penc;
@@ -60,7 +103,10 @@ void enc_free(Encoder **penc)
if (!enc)
return;
+enc_thread_stop(enc);
+
av_frame_free(&enc->sq_frame);
+av_frame_free(&enc->sub_frame);
av_packet_free(&enc->pkt);
@@ -77,6 +123,12 @@ int enc_alloc(Encoder **penc, const AVCodec *codec)
if (!enc)
return AVERROR(ENOMEM);
+if (codec->type == AVMEDIA_TYPE_SUBTITLE) {
+enc->sub_frame = av_frame_alloc();
+if (!enc->sub_frame)
+goto fail;
+}
+
enc->pkt = av_packet_alloc();
if (!enc->pkt)
goto fail;
@@ -165,6 +217,52 @@ static int set_encoder_id(OutputFile *of, OutputStream
*ost)
return 0;
}
+static void *encoder_thread(void *arg);
+
+static int enc_thread_start(OutputStream *ost)
+{
+Encoder *e = ost->enc;
+ObjPool *op;
+int ret = 0;
+
+op = objpool_alloc_frames();
+if (!op)
+return AVERROR(ENOMEM);
+
+e->queue_in = tq_alloc(1, 1, op, frame_move);
+if (!e->queue_in) {
+objpool_free(&op);
+return AVERROR(ENOMEM);
+}
+
+op = objpool_alloc_packets();
+if (!op)
+goto fail;
+
+e->queue_out = tq_alloc(1, 4, op, pkt_move);
+if (!e->queue_out) {
+objpool_free(&op);
+goto fail;
+}
+
+ret = pthread_create(&e->thread, NULL, encoder_thread, ost);
+if (ret) {
+ret = AVERROR(ret);
+av_log(ost, AV_LOG_ERROR, "pthread_create() failed: %s\n",
+ av_err2str(ret));
+goto fail;
+}
+
+return 0;
+fail:
+if (ret >= 0)
+ret = AVERROR(ENOMEM);
+
+tq_free(&e->queue_in);
+tq_free(&e->queue_out);
+return ret;
+}
+
int enc_open(OutputStream *ost, const AVFrame *frame)
{
InputStream *ist = ost->ist;
@@ -373,6 +471,13 @@ int enc_open(OutputStream *ost, const AVFrame *frame)
if (ost->st->time_base.num <= 0 || ost->st->time_base.den <= 0)
ost->st->time_base = av_add_q(ost->enc_ctx->time_base, (AVRational){0,
1});
+ret = enc_thread_start(ost);
+if (ret < 0) {
+av_log(ost, AV_LOG_ERROR, "Error starting encoder thread: %s\n",
+ av_err2str(ret));
+return ret;
+}
+
ret = of_stream_init(of, ost);
if (ret < 0)
return ret;
@@ -386,19 +491,18 @@ static int check_recording_time(OutputStream *ost,
int64_t ts, AVRational tb)
if (of->recording_time != INT64_MAX &&
av_compare_ts(ts, tb, of->recording_time, AV_TIME_BASE_Q) >= 0) {
-close_output_stream(ost);
return 0;
}
return 1;
}
-int enc_subtitle(OutputFile *of, OutputStr
[FFmpeg-devel] [PATCH 07/10] fftools/ffmpeg_demux: switch from AVThreadMessageQueue to ThreadQueue
* the code is made shorter and simpler
* avoids constantly allocating and freeing AVPackets, thanks to
ThreadQueue integration with ObjPool
* is consistent with decoding/filtering/muxing
* reduces the diff in the future switch to thread-aware scheduling
This makes ifile_get_packet() always block. Any potential issues caused
by this will be resolved by the switch to thread-aware scheduling in
future commits.
---
fftools/ffmpeg.c| 32 ++--
fftools/ffmpeg.h| 3 +-
fftools/ffmpeg_demux.c | 108 ++--
fftools/ffmpeg_filter.c | 5 +-
4 files changed, 58 insertions(+), 90 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 61fcda2526..cf8a50bffc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1043,9 +1043,6 @@ static int check_keyboard_interaction(int64_t cur_time)
static void reset_eagain(void)
{
-int i;
-for (i = 0; i < nb_input_files; i++)
-input_files[i]->eagain = 0;
for (OutputStream *ost = ost_iter(NULL); ost; ost = ost_iter(ost))
ost->unavailable = 0;
}
@@ -1069,19 +1066,14 @@ static void decode_flush(InputFile *ifile)
* this function should be called again
* - AVERROR_EOF -- this function should not be called again
*/
-static int process_input(int file_index)
+static int process_input(int file_index, AVPacket *pkt)
{
InputFile *ifile = input_files[file_index];
InputStream *ist;
-AVPacket *pkt;
int ret, i;
-ret = ifile_get_packet(ifile, &pkt);
+ret = ifile_get_packet(ifile, pkt);
-if (ret == AVERROR(EAGAIN)) {
-ifile->eagain = 1;
-return ret;
-}
if (ret == 1) {
/* the input file is looped: flush the decoders */
decode_flush(ifile);
@@ -1128,7 +1120,7 @@ static int process_input(int file_index)
ret = process_input_packet(ist, pkt, 0);
-av_packet_free(&pkt);
+av_packet_unref(pkt);
return ret < 0 ? ret : 0;
}
@@ -1138,7 +1130,7 @@ static int process_input(int file_index)
*
* @return 0 for success, <0 for error
*/
-static int transcode_step(OutputStream *ost)
+static int transcode_step(OutputStream *ost, AVPacket *demux_pkt)
{
InputStream *ist = NULL;
int ret;
@@ -1153,10 +1145,8 @@ static int transcode_step(OutputStream *ost)
av_assert0(ist);
}
-ret = process_input(ist->file_index);
+ret = process_input(ist->file_index, demux_pkt);
if (ret == AVERROR(EAGAIN)) {
-if (input_files[ist->file_index]->eagain)
-ost->unavailable = 1;
return 0;
}
@@ -1182,12 +1172,19 @@ static int transcode(int *err_rate_exceeded)
int ret = 0, i;
InputStream *ist;
int64_t timer_start;
+AVPacket *demux_pkt = NULL;
print_stream_maps();
*err_rate_exceeded = 0;
atomic_store(&transcode_init_done, 1);
+demux_pkt = av_packet_alloc();
+if (!demux_pkt) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+
if (stdin_interaction) {
av_log(NULL, AV_LOG_INFO, "Press [q] to stop, [?] for help\n");
}
@@ -1215,7 +1212,7 @@ static int transcode(int *err_rate_exceeded)
break;
}
-ret = transcode_step(ost);
+ret = transcode_step(ost, demux_pkt);
if (ret < 0 && ret != AVERROR_EOF) {
av_log(NULL, AV_LOG_ERROR, "Error while filtering: %s\n",
av_err2str(ret));
break;
@@ -1256,6 +1253,9 @@ static int transcode(int *err_rate_exceeded)
/* dump report by using the first video and audio streams */
print_report(1, timer_start, av_gettime_relative());
+fail:
+av_packet_free(&demux_pkt);
+
return ret;
}
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index f50222472c..3c153021f8 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -407,7 +407,6 @@ typedef struct InputFile {
AVFormatContext *ctx;
int eof_reached; /* true if eof reached */
-int eagain; /* true if last read attempt returned EAGAIN */
int64_t input_ts_offset;
int input_sync_ref;
/**
@@ -859,7 +858,7 @@ void ifile_close(InputFile **f);
* caller should flush decoders and read from this demuxer again
* - a negative error code on failure
*/
-int ifile_get_packet(InputFile *f, AVPacket **pkt);
+int ifile_get_packet(InputFile *f, AVPacket *pkt);
int ist_output_add(InputStream *ist, OutputStream *ost);
int ist_filter_add(InputStream *ist, InputFilter *ifilter, int is_simple);
diff --git a/fftools/ffmpeg_demux.c b/fftools/ffmpeg_demux.c
index 791952f120..65a5e08ca5 100644
--- a/fftools/ffmpeg_demux.c
+++ b/fftools/ffmpeg_demux.c
@@ -21,6 +21,8 @@
#include "ffmpeg.h"
#include "ffmpeg_utils.h"
+#include "objpool.h"
+#include "thread_queue.h"
#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
@@ -33,7 +35,6 @@
#include "libavutil/time.h"
#include "libavutil/timestamp.h"
#include "libavutil/thread.h"
-#include "libavutil/threadmessage.h
[FFmpeg-devel] [PATCH 06/10] fftools/ffmpeg_mux: move bitstream filtering to the muxer thread
This will be the appropriate place for it after the rest of transcoding
is switched to a threaded architecture.
---
fftools/ffmpeg_mux.c | 112 ++-
1 file changed, 67 insertions(+), 45 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 82352b7981..57fb8a8413 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -207,6 +207,67 @@ static int sync_queue_process(Muxer *mux, OutputStream
*ost, AVPacket *pkt, int
return 0;
}
+/* apply the output bitstream filters */
+static int mux_packet_filter(Muxer *mux, OutputStream *ost,
+ AVPacket *pkt, int *stream_eof)
+{
+MuxStream *ms = ms_from_ost(ost);
+const char *err_msg;
+int ret = 0;
+
+if (ms->bsf_ctx) {
+int bsf_eof = 0;
+
+if (pkt)
+av_packet_rescale_ts(pkt, pkt->time_base,
ms->bsf_ctx->time_base_in);
+
+ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
+if (ret < 0) {
+err_msg = "submitting a packet for bitstream filtering";
+goto fail;
+}
+
+while (!bsf_eof) {
+ret = av_bsf_receive_packet(ms->bsf_ctx, ms->bsf_pkt);
+if (ret == AVERROR(EAGAIN))
+return 0;
+else if (ret == AVERROR_EOF)
+bsf_eof = 1;
+else if (ret < 0) {
+av_log(ost, AV_LOG_ERROR,
+ "Error applying bitstream filters to a packet: %s",
+ av_err2str(ret));
+if (exit_on_error)
+return ret;
+continue;
+}
+
+if (!bsf_eof)
+ms->bsf_pkt->time_base = ms->bsf_ctx->time_base_out;
+
+ret = sync_queue_process(mux, ost, bsf_eof ? NULL : ms->bsf_pkt,
stream_eof);
+if (ret < 0)
+goto mux_fail;
+}
+*stream_eof = 1;
+return AVERROR_EOF;
+} else {
+ret = sync_queue_process(mux, ost, pkt, stream_eof);
+if (ret < 0)
+goto mux_fail;
+}
+
+return 0;
+
+mux_fail:
+err_msg = "submitting a packet to the muxer";
+
+fail:
+if (ret != AVERROR_EOF)
+av_log(ost, AV_LOG_ERROR, "Error %s: %s\n", err_msg, av_err2str(ret));
+return ret;
+}
+
static void thread_set_name(OutputFile *of)
{
char name[16];
@@ -263,7 +324,7 @@ static void *muxer_thread(void *arg)
}
ost = of->streams[stream_idx];
-ret = sync_queue_process(mux, ost, ret < 0 ? NULL : mt.pkt,
&stream_eof);
+ret = mux_packet_filter(mux, ost, ret < 0 ? NULL : mt.pkt,
&stream_eof);
av_packet_unref(mt.pkt);
if (ret == AVERROR_EOF) {
if (stream_eof) {
@@ -376,58 +437,19 @@ static int submit_packet(Muxer *mux, AVPacket *pkt,
OutputStream *ost)
int of_output_packet(OutputFile *of, OutputStream *ost, AVPacket *pkt)
{
Muxer *mux = mux_from_of(of);
-MuxStream *ms = ms_from_ost(ost);
-const char *err_msg;
int ret = 0;
if (pkt && pkt->dts != AV_NOPTS_VALUE)
ost->last_mux_dts = av_rescale_q(pkt->dts, pkt->time_base,
AV_TIME_BASE_Q);
-/* apply the output bitstream filters */
-if (ms->bsf_ctx) {
-int bsf_eof = 0;
-
-if (pkt)
-av_packet_rescale_ts(pkt, pkt->time_base,
ms->bsf_ctx->time_base_in);
-
-ret = av_bsf_send_packet(ms->bsf_ctx, pkt);
-if (ret < 0) {
-err_msg = "submitting a packet for bitstream filtering";
-goto fail;
-}
-
-while (!bsf_eof) {
-ret = av_bsf_receive_packet(ms->bsf_ctx, ms->bsf_pkt);
-if (ret == AVERROR(EAGAIN))
-return 0;
-else if (ret == AVERROR_EOF)
-bsf_eof = 1;
-else if (ret < 0) {
-err_msg = "applying bitstream filters to a packet";
-goto fail;
-}
-
-if (!bsf_eof)
-ms->bsf_pkt->time_base = ms->bsf_ctx->time_base_out;
-
-ret = submit_packet(mux, bsf_eof ? NULL : ms->bsf_pkt, ost);
-if (ret < 0)
-goto mux_fail;
-}
-} else {
-ret = submit_packet(mux, pkt, ost);
-if (ret < 0)
-goto mux_fail;
+ret = submit_packet(mux, pkt, ost);
+if (ret < 0) {
+av_log(ost, AV_LOG_ERROR, "Error submitting a packet to the muxer: %s",
+ av_err2str(ret));
+return ret;
}
return 0;
-
-mux_fail:
-err_msg = "submitting a packet to the muxer";
-
-fail:
-av_log(ost, AV_LOG_ERROR, "Error %s\n", err_msg);
-return exit_on_error ? ret : 0;
}
int of_streamcopy(OutputStream *ost, const AVPacket *pkt, int64_t dts)
--
2.42.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 w
[FFmpeg-devel] [PATCH 04/10] fftools/ffmpeg_filter: reindent
---
fftools/ffmpeg_filter.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 1800296aa4..1df1212442 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -2526,17 +2526,17 @@ static int sub2video_frame(InputFilter *ifilter,
AVFrame *frame)
return 0;
}
-if (!frame) {
-if (ifp->sub2video.end_pts < INT64_MAX)
-sub2video_update(ifp, INT64_MAX, NULL);
+if (!frame) {
+if (ifp->sub2video.end_pts < INT64_MAX)
+sub2video_update(ifp, INT64_MAX, NULL);
-return av_buffersrc_add_frame(ifp->filter, NULL);
-}
+return av_buffersrc_add_frame(ifp->filter, NULL);
+}
-ifp->width = frame->width ? frame->width : ifp->width;
-ifp->height = frame->height ? frame->height : ifp->height;
+ifp->width = frame->width ? frame->width : ifp->width;
+ifp->height = frame->height ? frame->height : ifp->height;
-sub2video_update(ifp, INT64_MIN, (const
AVSubtitle*)frame->buf[0]->data);
+sub2video_update(ifp, INT64_MIN, (const AVSubtitle*)frame->buf[0]->data);
return 0;
}
--
2.42.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 05/10] fftools/ffmpeg_mux: add muxing thread private data
To be used for data that never needs to be visible outside of the muxer
thread. Start by moving the muxed AVPacket in there.
---
fftools/ffmpeg_mux.c | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/fftools/ffmpeg_mux.c b/fftools/ffmpeg_mux.c
index 30c033036d..82352b7981 100644
--- a/fftools/ffmpeg_mux.c
+++ b/fftools/ffmpeg_mux.c
@@ -39,6 +39,10 @@
#include "libavformat/avformat.h"
#include "libavformat/avio.h"
+typedef struct MuxThreadContext {
+AVPacket *pkt;
+} MuxThreadContext;
+
int want_sdp = 1;
static Muxer *mux_from_of(OutputFile *of)
@@ -210,18 +214,40 @@ static void thread_set_name(OutputFile *of)
ff_thread_setname(name);
}
+static void mux_thread_uninit(MuxThreadContext *mt)
+{
+av_packet_free(&mt->pkt);
+
+memset(mt, 0, sizeof(*mt));
+}
+
+static int mux_thread_init(MuxThreadContext *mt)
+{
+memset(mt, 0, sizeof(*mt));
+
+mt->pkt = av_packet_alloc();
+if (!mt->pkt)
+goto fail;
+
+return 0;
+
+fail:
+mux_thread_uninit(mt);
+return AVERROR(ENOMEM);
+}
+
static void *muxer_thread(void *arg)
{
Muxer *mux = arg;
OutputFile *of = &mux->of;
-AVPacket *pkt = NULL;
+
+MuxThreadContext mt;
+
intret = 0;
-pkt = av_packet_alloc();
-if (!pkt) {
-ret = AVERROR(ENOMEM);
+ret = mux_thread_init(&mt);
+if (ret < 0)
goto finish;
-}
thread_set_name(of);
@@ -229,7 +255,7 @@ static void *muxer_thread(void *arg)
OutputStream *ost;
int stream_idx, stream_eof = 0;
-ret = tq_receive(mux->tq, &stream_idx, pkt);
+ret = tq_receive(mux->tq, &stream_idx, mt.pkt);
if (stream_idx < 0) {
av_log(mux, AV_LOG_VERBOSE, "All streams finished\n");
ret = 0;
@@ -237,8 +263,8 @@ static void *muxer_thread(void *arg)
}
ost = of->streams[stream_idx];
-ret = sync_queue_process(mux, ost, ret < 0 ? NULL : pkt, &stream_eof);
-av_packet_unref(pkt);
+ret = sync_queue_process(mux, ost, ret < 0 ? NULL : mt.pkt,
&stream_eof);
+av_packet_unref(mt.pkt);
if (ret == AVERROR_EOF) {
if (stream_eof) {
tq_receive_finish(mux->tq, stream_idx);
@@ -254,7 +280,7 @@ static void *muxer_thread(void *arg)
}
finish:
-av_packet_free(&pkt);
+mux_thread_uninit(&mt);
for (unsigned int i = 0; i < mux->fc->nb_streams; i++)
tq_receive_finish(mux->tq, i);
--
2.42.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 02/10] fftools/ffmpeg_filter: move filtering to a separate thread
As previously for decoding, this is merely "scaffolding" for moving to a
fully threaded architecture and does not yet make filtering truly
parallel - the main thread will currently wait for the filtering thread
to finish its work before continuing. That will change in future commits
after encoders are also moved to threads and a thread-aware scheduler is
added.
---
fftools/ffmpeg.h| 9 +-
fftools/ffmpeg_dec.c| 39 +-
fftools/ffmpeg_filter.c | 827 ++--
3 files changed, 732 insertions(+), 143 deletions(-)
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 1f11a2f002..f50222472c 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -80,6 +80,14 @@ enum HWAccelID {
HWACCEL_GENERIC,
};
+enum FrameOpaque {
+FRAME_OPAQUE_REAP_FILTERS = 1,
+FRAME_OPAQUE_CHOOSE_INPUT,
+FRAME_OPAQUE_SUB_HEARTBEAT,
+FRAME_OPAQUE_EOF,
+FRAME_OPAQUE_SEND_COMMAND,
+};
+
typedef struct HWDevice {
const char *name;
enum AVHWDeviceType type;
@@ -730,7 +738,6 @@ const FrameData *frame_data_c(AVFrame *frame);
int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame, int
keep_reference);
int ifilter_send_eof(InputFilter *ifilter, int64_t pts, AVRational tb);
-int ifilter_sub2video(InputFilter *ifilter, const AVFrame *frame);
void ifilter_sub2video_heartbeat(InputFilter *ifilter, int64_t pts, AVRational
tb);
/**
diff --git a/fftools/ffmpeg_dec.c b/fftools/ffmpeg_dec.c
index 517d6b3ced..b60bad1220 100644
--- a/fftools/ffmpeg_dec.c
+++ b/fftools/ffmpeg_dec.c
@@ -147,11 +147,12 @@ fail:
static int send_frame_to_filters(InputStream *ist, AVFrame *decoded_frame)
{
-int i, ret;
+int i, ret = 0;
-av_assert1(ist->nb_filters > 0); /* ensure ret is initialized */
for (i = 0; i < ist->nb_filters; i++) {
-ret = ifilter_send_frame(ist->filters[i], decoded_frame, i <
ist->nb_filters - 1);
+ret = ifilter_send_frame(ist->filters[i], decoded_frame,
+ i < ist->nb_filters - 1 ||
+ ist->dec->type == AVMEDIA_TYPE_SUBTITLE);
if (ret == AVERROR_EOF)
ret = 0; /* ignore */
if (ret < 0) {
@@ -380,15 +381,6 @@ static int video_frame_process(InputStream *ist, AVFrame
*frame)
return 0;
}
-static void sub2video_flush(InputStream *ist)
-{
-for (int i = 0; i < ist->nb_filters; i++) {
-int ret = ifilter_sub2video(ist->filters[i], NULL);
-if (ret != AVERROR_EOF && ret < 0)
-av_log(NULL, AV_LOG_WARNING, "Flush the frame error.\n");
-}
-}
-
static int process_subtitle(InputStream *ist, AVFrame *frame)
{
Decoder *d = ist->decoder;
@@ -426,14 +418,9 @@ static int process_subtitle(InputStream *ist, AVFrame
*frame)
if (!subtitle)
return 0;
-for (int i = 0; i < ist->nb_filters; i++) {
-ret = ifilter_sub2video(ist->filters[i], frame);
-if (ret < 0) {
-av_log(ist, AV_LOG_ERROR, "Error sending a subtitle for filtering:
%s\n",
- av_err2str(ret));
-return ret;
-}
-}
+ret = send_frame_to_filters(ist, frame);
+if (ret < 0)
+return ret;
subtitle = (AVSubtitle*)frame->buf[0]->data;
if (!subtitle->num_rects)
@@ -824,14 +811,10 @@ finish:
return ret;
// signal EOF to our downstreams
-if (ist->dec->type == AVMEDIA_TYPE_SUBTITLE)
-sub2video_flush(ist);
-else {
-ret = send_filter_eof(ist);
-if (ret < 0) {
-av_log(NULL, AV_LOG_FATAL, "Error marking filters as finished\n");
-return ret;
-}
+ret = send_filter_eof(ist);
+if (ret < 0) {
+av_log(NULL, AV_LOG_FATAL, "Error marking filters as finished\n");
+return ret;
}
return AVERROR_EOF;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 69c28a6b2b..d845448332 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -21,6 +21,8 @@
#include
#include "ffmpeg.h"
+#include "ffmpeg_utils.h"
+#include "thread_queue.h"
#include "libavfilter/avfilter.h"
#include "libavfilter/buffersink.h"
@@ -53,12 +55,50 @@ typedef struct FilterGraphPriv {
int is_meta;
int disable_conversions;
+int nb_inputs_bound;
+int nb_outputs_bound;
+
const char *graph_desc;
// frame for temporarily holding output from the filtergraph
AVFrame *frame;
// frame for sending output to the encoder
AVFrame *frame_enc;
+
+pthread_tthread;
+/**
+ * Queue for sending frames from the main thread to the filtergraph. Has
+ * nb_inputs+1 streams - the first nb_inputs stream correspond to
+ * filtergraph inputs. Frames on those streams may have their opaque set to
+ * - FRAME_OPAQUE_EOF: frame contains no data, but pts+timebase of the
+ * EOF event for the correspondint stream. Will be immediately followed
by
+ * this stream being send-closed.
+
[FFmpeg-devel] [PATCH v3] ffmpeg CLI multithreading
Hi, this should hopefully be the last version of this set. If nobody has new comments, I will push it in a few days. Cheers, -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 01/10] fftools/ffmpeg_filter: make sub2video heartbeat more robust
Avoid making decisions based on current graph input state, which makes the output dependent on the order in which the frames from different inputs are interleaved. Makes the output of fate-filter-overlay-dvdsub-2397 more correct - the subtitle appears two frames later, which is closer to its PTS as stored in the file. --- fftools/ffmpeg_filter.c | 3 +-- tests/ref/fate/filter-overlay-dvdsub-2397 | 4 ++-- tests/ref/fate/sub2video | 8 +--- 3 files changed, 8 insertions(+), 7 deletions(-) diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c index 3172ae25ec..69c28a6b2b 100644 --- a/fftools/ffmpeg_filter.c +++ b/fftools/ffmpeg_filter.c @@ -2280,8 +2280,7 @@ void ifilter_sub2video_heartbeat(InputFilter *ifilter, int64_t pts, AVRational t or if we need to initialize the system, update the overlayed subpicture and its start/end times */ sub2video_update(ifp, pts2 + 1, NULL); - -if (av_buffersrc_get_nb_failed_requests(ifp->filter)) +else sub2video_push_ref(ifp, pts2); } diff --git a/tests/ref/fate/filter-overlay-dvdsub-2397 b/tests/ref/fate/filter-overlay-dvdsub-2397 index 7df4f50776..45c026f540 100644 --- a/tests/ref/fate/filter-overlay-dvdsub-2397 +++ b/tests/ref/fate/filter-overlay-dvdsub-2397 @@ -489,12 +489,12 @@ 1, 3877, 3877, 10, 2013, 0x95a39f9c 1, 3887, 3887, 10, 2013, 0x4f7ea123 1, 3897, 3897, 10, 2013, 0x9efb9ba1 -0,117,117,1, 518400, 0xbf8523da +0,117,117,1, 518400, 0x61e0f688 1, 3907, 3907, 10, 2013, 0xf395b2cd 1, 3917, 3917, 10, 2013, 0x261a881e 1, 3927, 3927, 10, 2013, 0x7f2d9f72 1, 3937, 3937, 10, 2013, 0x0105b38d -0,118,118,1, 518400, 0x41890ed6 +0,118,118,1, 518400, 0xa47de755 1, 3952, 3952, 10, 2013, 0x0e5db67e 1, 3962, 3962, 10, 2013, 0xfc9baf97 0,119,119,1, 518400, 0x588534fc diff --git a/tests/ref/fate/sub2video b/tests/ref/fate/sub2video index 80abe9c905..76347322f3 100644 --- a/tests/ref/fate/sub2video +++ b/tests/ref/fate/sub2video @@ -68,7 +68,8 @@ 0,258,258,1, 518400, 0x34cdddee 0,269,269,1, 518400, 0xbab197ea 1, 5391, 5391, 2696000, 2095, 0x61bb15ed -0,270,270,1, 518400, 0x4db4ce51 +0,270,270,1, 518400, 0xbab197ea +0,271,271,1, 518400, 0x4db4ce51 0,283,283,1, 518400, 0xbab197ea 1, 56663000, 56663000, 1262000, 1013, 0xc9ae89b7 0,284,284,1, 518400, 0xe6bc0ea9 @@ -137,7 +138,7 @@ 1, 168049000, 168049000, 190, 1312, 0x0bf20e8d 0,850,850,1, 518400, 0xbab197ea 1, 170035000, 170035000, 1524000, 1279, 0xb6c2dafe -0,851,851,1, 518400, 0x8780239e +0,851,851,1, 518400, 0xbab197ea 0,858,858,1, 518400, 0xbab197ea 0,861,861,1, 518400, 0x6eb72347 1, 172203000, 172203000, 1695000, 1826, 0x9a1ac769 @@ -161,7 +162,8 @@ 0,976,976,1, 518400, 0x923d1ce7 0,981,981,1, 518400, 0xbab197ea 1, 196361000, 196361000, 1524000, 1715, 0x695ca41e -0,982,982,1, 518400, 0x6e652cd2 +0,982,982,1, 518400, 0xbab197ea +0,983,983,1, 518400, 0x6e652cd2 0,989,989,1, 518400, 0xbab197ea 1, 197946000, 197946000, 116, 789, 0xc63a189e 0,990,990,1, 518400, 0x25113966 -- 2.42.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 03/10] fftools/ffmpeg_filter: buffer sub2video heartbeat frames like other frames
Otherwise they'd be silently ignored if received by the filtering thread
before the filtergraph can be initialized, which would make the output
dependent on the order in which frames from different inputs arrive.
---
fftools/ffmpeg_filter.c | 43 -
1 file changed, 25 insertions(+), 18 deletions(-)
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index d845448332..1800296aa4 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -1769,6 +1769,8 @@ static int graph_is_meta(AVFilterGraph *graph)
return 1;
}
+static int sub2video_frame(InputFilter *ifilter, AVFrame *frame);
+
static int configure_filtergraph(FilterGraph *fg, const FilterGraphThread *fgt)
{
FilterGraphPriv *fgp = fgp_from_fg(fg);
@@ -1880,7 +1882,7 @@ static int configure_filtergraph(FilterGraph *fg, const
FilterGraphThread *fgt)
AVFrame *tmp;
while (av_fifo_read(ifp->frame_queue, &tmp, 1) >= 0) {
if (ifp->type_src == AVMEDIA_TYPE_SUBTITLE) {
-sub2video_update(ifp, INT64_MIN, (const
AVSubtitle*)tmp->buf[0]->data);
+sub2video_frame(&ifp->ifilter, tmp);
} else {
ret = av_buffersrc_add_frame(ifp->filter, tmp);
}
@@ -2475,9 +2477,6 @@ static void sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational tb
InputFilterPriv *ifp = ifp_from_ifilter(ifilter);
int64_t pts2;
-if (!ifilter->graph->graph)
-return;
-
/* subtitles seem to be usually muxed ahead of other streams;
if not, subtracting a larger time here is necessary */
pts2 = av_rescale_q(pts, tb, ifp->time_base) - 1;
@@ -2495,18 +2494,38 @@ static void sub2video_heartbeat(InputFilter *ifilter,
int64_t pts, AVRational tb
sub2video_push_ref(ifp, pts2);
}
-static int sub2video_frame(InputFilter *ifilter, const AVFrame *frame)
+static int sub2video_frame(InputFilter *ifilter, AVFrame *frame)
{
InputFilterPriv *ifp = ifp_from_ifilter(ifilter);
int ret;
+if (!ifilter->graph->graph) {
+AVFrame *tmp;
+
+if (!frame)
+return 0;
+
+tmp = av_frame_alloc();
+if (!tmp)
+return AVERROR(ENOMEM);
+
+av_frame_move_ref(tmp, frame);
+
+ret = av_fifo_write(ifp->frame_queue, &tmp, 1);
+if (ret < 0) {
+av_frame_free(&tmp);
+return ret;
+}
+
+return 0;
+}
+
// heartbeat frame
if (frame && !frame->buf[0]) {
sub2video_heartbeat(ifilter, frame->pts, frame->time_base);
return 0;
}
-if (ifilter->graph->graph) {
if (!frame) {
if (ifp->sub2video.end_pts < INT64_MAX)
sub2video_update(ifp, INT64_MAX, NULL);
@@ -2518,18 +2537,6 @@ static int sub2video_frame(InputFilter *ifilter, const
AVFrame *frame)
ifp->height = frame->height ? frame->height : ifp->height;
sub2video_update(ifp, INT64_MIN, (const
AVSubtitle*)frame->buf[0]->data);
-} else if (frame) {
-AVFrame *tmp = av_frame_clone(frame);
-
-if (!tmp)
-return AVERROR(ENOMEM);
-
-ret = av_fifo_write(ifp->frame_queue, &tmp, 1);
-if (ret < 0) {
-av_frame_free(&tmp);
-return ret;
-}
-}
return 0;
}
--
2.42.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] tests/fate: add pixelize filter tests
Attached. From c17589e4fc6b38013d6b0b14feeac50e00bb3305 Mon Sep 17 00:00:00 2001 From: Paul B Mahol Date: Wed, 6 Dec 2023 11:18:35 +0100 Subject: [PATCH] tests/fate: add pixelize filter tests Signed-off-by: Paul B Mahol --- tests/fate/filter-video.mak| 9 + tests/ref/fate/filter-pixelize-avg | 1 + tests/ref/fate/filter-pixelize-max | 1 + tests/ref/fate/filter-pixelize-min | 1 + 4 files changed, 12 insertions(+) create mode 100644 tests/ref/fate/filter-pixelize-avg create mode 100644 tests/ref/fate/filter-pixelize-max create mode 100644 tests/ref/fate/filter-pixelize-min diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak index e4bdf59db9..4defaf5877 100644 --- a/tests/fate/filter-video.mak +++ b/tests/fate/filter-video.mak @@ -532,6 +532,15 @@ fate-filter-thumbnail: CMD = video_filter "scale,thumbnail=10" FATE_FILTER_VSYNTH_VIDEO_FILTER-$(CONFIG_TILE_FILTER) += fate-filter-tile fate-filter-tile: CMD = video_filter "tile=3x3:nb_frames=5:padding=7:margin=2" +FATE_FILTER_VSYNTH_VIDEO_FILTER-$(CONFIG_PIXELIZE_FILTER) += fate-filter-pixelize-avg +fate-filter-pixelize-avg: CMD = video_filter "pixelize=mode=avg" + +FATE_FILTER_VSYNTH_VIDEO_FILTER-$(CONFIG_PIXELIZE_FILTER) += fate-filter-pixelize-min +fate-filter-pixelize-min: CMD = video_filter "pixelize=mode=min" + +FATE_FILTER_VSYNTH_VIDEO_FILTER-$(CONFIG_PIXELIZE_FILTER) += fate-filter-pixelize-max +fate-filter-pixelize-max: CMD = video_filter "pixelize=mode=max" + tests/pixfmts.mak: TAG = GEN tests/pixfmts.mak: ffmpeg$(PROGSSUF)$(EXESUF) | tests diff --git a/tests/ref/fate/filter-pixelize-avg b/tests/ref/fate/filter-pixelize-avg new file mode 100644 index 00..42bbbf9cd0 --- /dev/null +++ b/tests/ref/fate/filter-pixelize-avg @@ -0,0 +1 @@ +pixelize-avgdf03e58c3756dd4ecef6b6f50709c23e diff --git a/tests/ref/fate/filter-pixelize-max b/tests/ref/fate/filter-pixelize-max new file mode 100644 index 00..6746114802 --- /dev/null +++ b/tests/ref/fate/filter-pixelize-max @@ -0,0 +1 @@ +pixelize-maxdb60eb984b9aec61f3ee16ed798eca34 diff --git a/tests/ref/fate/filter-pixelize-min b/tests/ref/fate/filter-pixelize-min new file mode 100644 index 00..1014ac8a46 --- /dev/null +++ b/tests/ref/fate/filter-pixelize-min @@ -0,0 +1 @@ +pixelize-min3eacb4349fb19d11f4f96c19a1bdbbfa -- 2.42.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] [ANNOUNCE] upcoming vote: TC/CC elections
Quoting Niklas Haas (2023-12-05 12:01:48) > On Tue, 05 Dec 2023 11:07:33 +0100 Anton Khirnov wrote: > > Hi all, > > Both elections have now concluded. > > > > We have 36 votes for the CC election (70% turnout) and 38 votes for TC > > (75% turnout); raw votes in CSV format are attached. > > > > The CC members now are: > > * James Almer > > * Jean-Baptiste Kempf > > * Anton Khirnov > > * Ronald Bultje > > * Michael Niedermayer > > > > For TC, it seems that we have a tie. The system reports two winning > > sets, both of which contain: > > * Michael Niedermayer > > * Martin Storsjö > > * Mark Thompson > > * Anton Khirnov > > > > The final member is Jan Ekström in one set and Niklas Haas in the other. > > We should now consider how to break this tie. Some options suggested on > > IRC were: > > * run a new vote with just the two of them > > * randomly > > * have Rémi break the tie, as he said he accidentally voted incorrectly > > due to misinterpreting the documentation > > * expand the committee > > Rather than run a new vote, I would prefer to give the spot to Jan. All the other alternatives have major issues, so I'd go with this as the least bad option. Anyone against? -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 7/7] avcodec: add AV_CODEC_FLAG_CLEAR
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
doc/codecs.texi| 14 ++
libavcodec/avcodec.h | 4
libavcodec/decode.c| 6 ++
libavcodec/options_table.h | 1 +
libavcodec/version.h | 2 +-
6 files changed, 29 insertions(+), 1 deletion(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 416e2bec5e..f839504a64 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-12-xx - xxx - lavc 60.36.100 - avcodec.h
+ Add AV_CODEC_FLAG_CLEAR.
+
2023-12-xx - xxx - lavu 58.33.100 - imgutils.h
Add av_image_fill_color()
diff --git a/doc/codecs.texi b/doc/codecs.texi
index 5b950b4560..0504a535f2 100644
--- a/doc/codecs.texi
+++ b/doc/codecs.texi
@@ -76,6 +76,20 @@ Apply interlaced motion estimation.
Use closed gop.
@item output_corrupt
Output even potentially corrupted frames.
+@item clear
+Clear the contents of the video buffer before decoding the next picture to it.
+
+Usually if only a part of a picture is affected by a decode error then the
+decoder (if it implements error concealment) tries to hide it by interpolating
+pixels from neighbouring areas or in some cases from the previous frame. Even
+without error concealment it is quite likely that the affected area will
+contain pixels from an earlier frame, due to frame pooling.
+
+For quality checking this might not be desirable, because it makes the errors
+less noticable. By using this flag, and combining it with disabled error
+concealment (@code{-ec 0}) it is possible to ensure that no leftover data from
+an earlier frame is presented in areas affected by decode errors.
+
@end table
@item time_base @var{rational number}
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7fb44e28f4..97848e942f 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -312,6 +312,10 @@ typedef struct RcOverride{
* loop filter.
*/
#define AV_CODEC_FLAG_LOOP_FILTER (1 << 11)
+/**
+ * Clear frame buffer contents before decoding.
+ */
+#define AV_CODEC_FLAG_CLEAR (1 << 12)
/**
* Only decode/encode grayscale.
*/
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 2cfb3fcf97..f9b18a2c35 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1675,6 +1675,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
validate_avframe_allocation(avctx, frame);
+if (avctx->flags & AV_CODEC_FLAG_CLEAR && avctx->codec_type ==
AVMEDIA_TYPE_VIDEO) {
+uint32_t color[4] = {0};
+ptrdiff_t linesize[4] = {frame->linesize[0], frame->linesize[1],
frame->linesize[2], frame->linesize[3]};
+av_image_fill_color(frame->data, linesize, frame->format, color,
frame->width, frame->height);
+}
+
ret = ff_attach_decode_data(frame);
if (ret < 0)
goto fail;
diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
index ee243d9894..23ff4cddf8 100644
--- a/libavcodec/options_table.h
+++ b/libavcodec/options_table.h
@@ -62,6 +62,7 @@ static const AVOption avcodec_options[] = {
{"frame_duration", "use frame durations", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_CODEC_FLAG_FRAME_DURATION}, .unit = "flags"},
{"pass1", "use internal 2-pass ratecontrol in first pass mode", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG_PASS1 }, INT_MIN, INT_MAX, 0, "flags"},
{"pass2", "use internal 2-pass ratecontrol in second pass mode", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG_PASS2 }, INT_MIN, INT_MAX, 0, "flags"},
+{"clear", "clear frames before decoding", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_CODEC_FLAG_CLEAR }, INT_MIN, INT_MAX, V|D, "flags"},
{"gray", "only decode/encode grayscale", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_CODEC_FLAG_GRAY }, INT_MIN, INT_MAX, V|E|D, "flags"},
{"psnr", "error[?] variables will be set during encoding", 0,
AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG_PSNR }, INT_MIN, INT_MAX, V|E,
"flags"},
{"ildct", "use interlaced DCT", 0, AV_OPT_TYPE_CONST, {.i64 =
AV_CODEC_FLAG_INTERLACED_DCT }, INT_MIN, INT_MAX, V|E, "flags"},
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 1008fead27..34b059a8a9 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
#include "version_major.h"
-#define LIBAVCODEC_VERSION_MINOR 35
+#define LIBAVCODEC_VERSION_MINOR 36
#define LIBAVCODEC_VERSION_MICRO 100
#define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
--
2.35.3
___
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 6/7] avutil/imgutils: add new function av_image_fill_color()
Signed-off-by: Marton Balint
---
doc/APIchanges | 3 +++
libavutil/imgutils.c | 4 ++--
libavutil/imgutils.h | 30 ++
libavutil/version.h | 2 +-
4 files changed, 36 insertions(+), 3 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 4a2dc1c44f..416e2bec5e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2023-02-09
API changes, most recent first:
+2023-12-xx - xxx - lavu 58.33.100 - imgutils.h
+ Add av_image_fill_color()
+
2023-11-08 - b82957a66a7 - lavu 58.32.100 - channel_layout.h
Add AV_CH_LAYOUT_7POINT2POINT3 and AV_CHANNEL_LAYOUT_7POINT2POINT3.
Add AV_CH_LAYOUT_9POINT1POINT4_BACK and AV_CHANNEL_LAYOUT_9POINT1POINT4_BACK.
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 278e30ee0f..e1eefcdd70 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -579,7 +579,7 @@ static void memset_bytes(uint8_t *dst, size_t dst_size,
uint8_t *clear,
// if it's a subsampled packed format).
#define MAX_BLOCK_SIZE 32
-static int image_fill_color(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
+int av_image_fill_color(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
enum AVPixelFormat pix_fmt, const uint32_t color[4],
int width, int height)
{
@@ -713,5 +713,5 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
colors[c] = color;
}
-return image_fill_color(dst_data, dst_linesize, pix_fmt, colors, width,
height);
+return av_image_fill_color(dst_data, dst_linesize, pix_fmt, colors, width,
height);
}
diff --git a/libavutil/imgutils.h b/libavutil/imgutils.h
index fa3bb101b1..6e744b0cac 100644
--- a/libavutil/imgutils.h
+++ b/libavutil/imgutils.h
@@ -339,6 +339,36 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
enum AVPixelFormat pix_fmt, enum AVColorRange range,
int width, int height);
+/**
+ * Overwrite the image data with a color. This is suitable for filling a
+ * sub-rectangle of an image, meaning the padding between the right most pixel
+ * and the left most pixel on the next line will not be overwritten. For some
+ * formats, the image size might be rounded up due to inherent alignment.
+ *
+ * If the pixel format has alpha, it is also replaced. Color component values
+ * are interpreted as native integers (or intfloats) regardless of actual pixel
+ * format endianness.
+ *
+ * This can return an error if the pixel format is not supported. Normally, all
+ * non-hwaccel pixel formats should be supported.
+ *
+ * Passing NULL for dst_data is allowed. Then the function returns whether the
+ * operation would have succeeded. (It can return an error if the pix_fmt is
+ * not supported.)
+ *
+ * @param dst_data data pointers to destination image
+ * @param dst_linesize linesizes for the destination image
+ * @param pix_fmt the pixel format of the image
+ * @param color the color components to be used for the fill
+ * @param width the width of the image in pixels
+ * @param heightthe height of the image in pixels
+ * @return 0 if the image data was filled, a negative AVERROR code otherwise
+ */
+int av_image_fill_color(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
+enum AVPixelFormat pix_fmt, const uint32_t color[4],
+int width, int height);
+
+
/**
* @}
*/
diff --git a/libavutil/version.h b/libavutil/version.h
index c5fa7c3692..0684996bf2 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 58
-#define LIBAVUTIL_VERSION_MINOR 32
+#define LIBAVUTIL_VERSION_MINOR 33
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.35.3
___
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 5/7] avutil/imgutils: factorize a fill color function
In preparation for making it public.
Signed-off-by: Marton Balint
---
libavutil/imgutils.c | 103 +++
1 file changed, 64 insertions(+), 39 deletions(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 67119b0870..278e30ee0f 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -579,30 +579,24 @@ static void memset_bytes(uint8_t *dst, size_t dst_size,
uint8_t *clear,
// if it's a subsampled packed format).
#define MAX_BLOCK_SIZE 32
-int av_image_fill_black(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
-enum AVPixelFormat pix_fmt, enum AVColorRange range,
+static int image_fill_color(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
+enum AVPixelFormat pix_fmt, const uint32_t color[4],
int width, int height)
{
const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
int nb_planes = av_pix_fmt_count_planes(pix_fmt);
-// A pixel or a group of pixels on each plane, with a value that
represents black.
+// A pixel or a group of pixels on each plane, with a value that
represents the color.
// Consider e.g. AV_PIX_FMT_UYVY422 for non-trivial cases.
uint8_t clear_block[4][MAX_BLOCK_SIZE] = {{0}}; // clear padding with 0
int clear_block_size[4] = {0};
ptrdiff_t plane_line_bytes[4] = {0};
-int rgb, xyz, pal, limited, alpha, bitstream, fltp;
+int bitstream;
int plane, c;
if (!desc || nb_planes < 1 || nb_planes > 4 || desc->flags &
AV_PIX_FMT_FLAG_HWACCEL)
return AVERROR(EINVAL);
-rgb = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
-xyz = !!(desc->flags & AV_PIX_FMT_FLAG_XYZ);
-pal = !!(desc->flags & AV_PIX_FMT_FLAG_PAL);
-limited = !rgb && !xyz && !pal && range != AVCOL_RANGE_JPEG;
-alpha = !pal && !!(desc->flags & AV_PIX_FMT_FLAG_ALPHA);
bitstream = !!(desc->flags & AV_PIX_FMT_FLAG_BITSTREAM);
-fltp = !!(desc->flags & AV_PIX_FMT_FLAG_FLOAT);
for (c = 0; c < desc->nb_components; c++) {
const AVComponentDescriptor comp = desc->comp[c];
@@ -623,7 +617,6 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
uint8_t *c_data[4];
const int c_linesize[4] = {0};
uint32_t src_array[MAX_BLOCK_SIZE];
-uint32_t src = 0;
int x;
if (comp.depth > 32)
@@ -631,35 +624,8 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
if (w < 1)
return AVERROR(EINVAL);
-if (pix_fmt == AV_PIX_FMT_MONOWHITE) {
-src = 1;
-} else if (c + 1 == desc->nb_components && alpha) {
-// (Assume even limited YUV uses full range alpha.)
-if (fltp) {
-if (comp.depth != 16 && comp.depth != 32)
-return AVERROR(EINVAL);
-src = (comp.depth == 16 ? 0x3C00 : 0x3F80); // 1.0
- } else {
-src = (comp.depth == 32 ? 0 : (1 << comp.depth)) - 1;
- }
-} else if (c == 0 && limited && comp.depth > 1) {
-if (comp.depth < 8 || (fltp && comp.depth != 16 && comp.depth !=
32))
-return AVERROR(EINVAL);
-if (fltp)
-src = (comp.depth == 16 ? 0x3000 : 0x3D80); // 0.0625
-else
-src = 16 << (comp.depth - 8);
-} else if ((c == 1 || c == 2) && !rgb && !xyz) {
-if (comp.depth < 8 || fltp && comp.depth != 16 && comp.depth != 32)
-return AVERROR(EINVAL);
-if (fltp)
-src = (comp.depth == 16 ? 0x3800 : 0x3F00); // 0.5
-else
-src = 128 << (comp.depth - 8);
-}
-
for (x = 0; x < w; x++)
-src_array[x] = src;
+src_array[x] = color[c];
for (x = 0; x < 4; x++)
c_data[x] = &clear_block[x][0];
@@ -690,3 +656,62 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
return 0;
}
+
+int av_image_fill_black(uint8_t * const dst_data[4], const ptrdiff_t
dst_linesize[4],
+enum AVPixelFormat pix_fmt, enum AVColorRange range,
+int width, int height)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+int nb_planes = av_pix_fmt_count_planes(pix_fmt);
+int rgb, xyz, pal, limited, alpha, fltp;
+uint32_t colors[4] = {0};
+
+if (!desc || nb_planes < 1 || nb_planes > 4 || desc->flags &
AV_PIX_FMT_FLAG_HWACCEL)
+return AVERROR(EINVAL);
+
+rgb = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
+xyz = !!(desc->flags & AV_PIX_FMT_FLAG_XYZ);
+pal = !!(desc->flags & AV_PIX_FMT_FLAG_PAL);
+limited = !rgb && !xyz && !pal && range != AVCOL_RANGE_JPEG;
+alpha = !pal && !!(desc->flags & AV_PIX_FMT_FLAG_ALPHA);
+fltp = !!(desc->flags & AV_PIX_FMT_FLAG_FLOAT);
+
+
[FFmpeg-devel] [PATCH v2 4/7] avutil/imgutils: add support for 32bit pixel format for av_image_fill_black()
Signed-off-by: Marton Balint
---
libavutil/imgutils.c| 33 +++--
tests/ref/fate/imgutils | 24
2 files changed, 35 insertions(+), 22 deletions(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index 5e401139c8..67119b0870 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -590,7 +590,7 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
uint8_t clear_block[4][MAX_BLOCK_SIZE] = {{0}}; // clear padding with 0
int clear_block_size[4] = {0};
ptrdiff_t plane_line_bytes[4] = {0};
-int rgb, xyz, pal, limited, alpha, bitstream;
+int rgb, xyz, pal, limited, alpha, bitstream, fltp;
int plane, c;
if (!desc || nb_planes < 1 || nb_planes > 4 || desc->flags &
AV_PIX_FMT_FLAG_HWACCEL)
@@ -602,6 +602,7 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
limited = !rgb && !xyz && !pal && range != AVCOL_RANGE_JPEG;
alpha = !pal && !!(desc->flags & AV_PIX_FMT_FLAG_ALPHA);
bitstream = !!(desc->flags & AV_PIX_FMT_FLAG_BITSTREAM);
+fltp = !!(desc->flags & AV_PIX_FMT_FLAG_FLOAT);
for (c = 0; c < desc->nb_components; c++) {
const AVComponentDescriptor comp = desc->comp[c];
@@ -621,11 +622,11 @@ int av_image_fill_black(uint8_t * const dst_data[4],
const ptrdiff_t dst_linesiz
int w = (bitstream ? 8 : 1) * clear_block_size[comp.plane] / comp.step;
uint8_t *c_data[4];
const int c_linesize[4] = {0};
-uint16_t src_array[MAX_BLOCK_SIZE];
-uint16_t src = 0;
+uint32_t src_array[MAX_BLOCK_SIZE];
+uint32_t src = 0;
int x;
-if (comp.depth > 16)
+if (comp.depth > 32)
return AVERROR(EINVAL);
if (w < 1)
return AVERROR(EINVAL);
@@ -634,15 +635,27 @@ int av_image_fill_black(uint8_t * const dst_data[4],
const ptrdiff_t dst_linesiz
src = 1;
} else if (c + 1 == desc->nb_components && alpha) {
// (Assume even limited YUV uses full range alpha.)
-src = (1 << comp.depth) - 1;
+if (fltp) {
+if (comp.depth != 16 && comp.depth != 32)
+return AVERROR(EINVAL);
+src = (comp.depth == 16 ? 0x3C00 : 0x3F80); // 1.0
+ } else {
+src = (comp.depth == 32 ? 0 : (1 << comp.depth)) - 1;
+ }
} else if (c == 0 && limited && comp.depth > 1) {
-if (comp.depth < 8)
+if (comp.depth < 8 || (fltp && comp.depth != 16 && comp.depth !=
32))
return AVERROR(EINVAL);
-src = 16 << (comp.depth - 8);
+if (fltp)
+src = (comp.depth == 16 ? 0x3000 : 0x3D80); // 0.0625
+else
+src = 16 << (comp.depth - 8);
} else if ((c == 1 || c == 2) && !rgb && !xyz) {
-if (comp.depth < 8)
+if (comp.depth < 8 || fltp && comp.depth != 16 && comp.depth != 32)
return AVERROR(EINVAL);
-src = 128 << (comp.depth - 8);
+if (fltp)
+src = (comp.depth == 16 ? 0x3800 : 0x3F00); // 0.5
+else
+src = 128 << (comp.depth - 8);
}
for (x = 0; x < w; x++)
@@ -651,7 +664,7 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
for (x = 0; x < 4; x++)
c_data[x] = &clear_block[x][0];
-av_write_image_line(src_array, c_data, c_linesize, desc, 0, 0, c, w);
+av_write_image_line2(src_array, c_data, c_linesize, desc, 0, 0, c, w,
4);
}
for (plane = 0; plane < nb_planes; plane++) {
diff --git a/tests/ref/fate/imgutils b/tests/ref/fate/imgutils
index c31bc38d77..fb2ed6d158 100644
--- a/tests/ref/fate/imgutils
+++ b/tests/ref/fate/imgutils
@@ -435,14 +435,14 @@ p016le total_size: 9216, black_unknown_crc:
0xfff85b60, black_tv_cr
p016be total_size: 9216, black_unknown_crc: 0x4d4d9903,
black_tv_crc: 0x4d4d9903, black_pc_crc: 0x69c6fe01
gray9be total_size: 6144, black_unknown_crc: 0xa913cdc7,
black_tv_crc: 0xa913cdc7, black_pc_crc: 0x
gray9le total_size: 6144, black_unknown_crc: 0x05a944de,
black_tv_crc: 0x05a944de, black_pc_crc: 0x
-gbrpf32be total_size: 36864, black_unknown_crc: --,
black_tv_crc: --, black_pc_crc: --
-gbrpf32le total_size: 36864, black_unknown_crc: --,
black_tv_crc: --, black_pc_crc: --
-gbrapf32be total_size: 49152, black_unknown_crc: --,
black_tv_crc: --, black_pc_crc: --
-gbrapf32le total_size: 49152, black_unknown_crc: --,
black_tv_crc: --, black_pc_crc: --
+gbrpf32be total_size: 36864, black_unknown_crc: 0x,
black_tv_crc: 0x, black_pc_crc: 0x
[FFmpeg-devel] [PATCH v2 3/7] avutil/imgutils: fix av_image_fill_black() for some pixel formats
- Fixes YA formats, because previous code always assumed alpha as the 4th
component.
- Fixes PAL format (as long as 0 is black, as in a systematic palette), because
previous code assumed it as limited Y.
- Fixes XYZ format because it does not need nonzero chroma components
- Fixes xv30be as the bitstream mode got merged to the non-bitstream mode.
Signed-off-by: Marton Balint
---
libavutil/imgutils.c| 49 +++--
tests/ref/fate/imgutils | 14 ++--
2 files changed, 25 insertions(+), 38 deletions(-)
diff --git a/libavutil/imgutils.c b/libavutil/imgutils.c
index da3812698e..5e401139c8 100644
--- a/libavutil/imgutils.c
+++ b/libavutil/imgutils.c
@@ -590,35 +590,18 @@ int av_image_fill_black(uint8_t * const dst_data[4],
const ptrdiff_t dst_linesiz
uint8_t clear_block[4][MAX_BLOCK_SIZE] = {{0}}; // clear padding with 0
int clear_block_size[4] = {0};
ptrdiff_t plane_line_bytes[4] = {0};
-int rgb, limited;
+int rgb, xyz, pal, limited, alpha, bitstream;
int plane, c;
if (!desc || nb_planes < 1 || nb_planes > 4 || desc->flags &
AV_PIX_FMT_FLAG_HWACCEL)
return AVERROR(EINVAL);
rgb = !!(desc->flags & AV_PIX_FMT_FLAG_RGB);
-limited = !rgb && range != AVCOL_RANGE_JPEG;
-
-if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM) {
-ptrdiff_t bytewidth = av_image_get_linesize(pix_fmt, width, 0);
-uint8_t *data;
-int mono = pix_fmt == AV_PIX_FMT_MONOWHITE || pix_fmt ==
AV_PIX_FMT_MONOBLACK;
-int fill = pix_fmt == AV_PIX_FMT_MONOWHITE ? 0xFF : 0;
-if (nb_planes != 1 || !(rgb || mono) || bytewidth < 1)
-return AVERROR(EINVAL);
-
-if (!dst_data)
-return 0;
-
-data = dst_data[0];
-
-// (Bitstream + alpha will be handled incorrectly - it'll remain
transparent.)
-for (;height > 0; height--) {
-memset(data, fill, bytewidth);
-data += dst_linesize[0];
-}
-return 0;
-}
+xyz = !!(desc->flags & AV_PIX_FMT_FLAG_XYZ);
+pal = !!(desc->flags & AV_PIX_FMT_FLAG_PAL);
+limited = !rgb && !xyz && !pal && range != AVCOL_RANGE_JPEG;
+alpha = !pal && !!(desc->flags & AV_PIX_FMT_FLAG_ALPHA);
+bitstream = !!(desc->flags & AV_PIX_FMT_FLAG_BITSTREAM);
for (c = 0; c < desc->nb_components; c++) {
const AVComponentDescriptor comp = desc->comp[c];
@@ -635,7 +618,7 @@ int av_image_fill_black(uint8_t * const dst_data[4], const
ptrdiff_t dst_linesiz
for (c = 0; c < desc->nb_components; c++) {
const AVComponentDescriptor comp = desc->comp[c];
// (Multiple pixels happen e.g. with AV_PIX_FMT_UYVY422.)
-int w = clear_block_size[comp.plane] / comp.step;
+int w = (bitstream ? 8 : 1) * clear_block_size[comp.plane] / comp.step;
uint8_t *c_data[4];
const int c_linesize[4] = {0};
uint16_t src_array[MAX_BLOCK_SIZE];
@@ -644,18 +627,22 @@ int av_image_fill_black(uint8_t * const dst_data[4],
const ptrdiff_t dst_linesiz
if (comp.depth > 16)
return AVERROR(EINVAL);
-if (!rgb && comp.depth < 8)
-return AVERROR(EINVAL);
if (w < 1)
return AVERROR(EINVAL);
-if (c == 0 && limited) {
-src = 16 << (comp.depth - 8);
-} else if ((c == 1 || c == 2) && !rgb) {
-src = 128 << (comp.depth - 8);
-} else if (c == 3) {
+if (pix_fmt == AV_PIX_FMT_MONOWHITE) {
+src = 1;
+} else if (c + 1 == desc->nb_components && alpha) {
// (Assume even limited YUV uses full range alpha.)
src = (1 << comp.depth) - 1;
+} else if (c == 0 && limited && comp.depth > 1) {
+if (comp.depth < 8)
+return AVERROR(EINVAL);
+src = 16 << (comp.depth - 8);
+} else if ((c == 1 || c == 2) && !rgb && !xyz) {
+if (comp.depth < 8)
+return AVERROR(EINVAL);
+src = 128 << (comp.depth - 8);
}
for (x = 0; x < w; x++)
diff --git a/tests/ref/fate/imgutils b/tests/ref/fate/imgutils
index f12bef3fb5..c31bc38d77 100644
--- a/tests/ref/fate/imgutils
+++ b/tests/ref/fate/imgutils
@@ -282,7 +282,7 @@ yuv411p total_size: 4608, black_unknown_crc:
0xd00f6cc6, black_tv_cr
graytotal_size: 3072, black_unknown_crc: 0x63e301a2,
black_tv_crc: 0x63e301a2, black_pc_crc: 0x
monow total_size:384, black_unknown_crc: 0x1ba3e150,
black_tv_crc: 0x1ba3e150, black_pc_crc: 0x1ba3e150
monob total_size:384, black_unknown_crc: 0x,
black_tv_crc: 0x, black_pc_crc: 0x
-pal8total_size: 4096, black_unknown_crc: 0x63e301a2,
black_tv_crc: 0x63e301a2, black_pc_crc: 0x
+pal8total_size: 4096, black_unknown_crc: 0x,
black_tv_crc: 0x, black_pc_crc: 0x
yuvj420ptotal_size:
[FFmpeg-devel] [PATCH v2 2/7] avutil/tests/imgutils: add tests for av_image_fill_black()
Signed-off-by: Marton Balint
---
libavutil/tests/imgutils.c | 61 +--
tests/ref/fate/imgutils| 217 +
2 files changed, 269 insertions(+), 9 deletions(-)
diff --git a/libavutil/tests/imgutils.c b/libavutil/tests/imgutils.c
index 1e2bb3fa01..582a358157 100644
--- a/libavutil/tests/imgutils.c
+++ b/libavutil/tests/imgutils.c
@@ -17,6 +17,7 @@
*/
#include "libavutil/imgutils.c"
+#include "libavutil/crc.h"
#undef printf
static int check_image_fill(enum AVPixelFormat pix_fmt, int w, int h) {
@@ -55,9 +56,44 @@ static int check_image_fill(enum AVPixelFormat pix_fmt, int
w, int h) {
return 0;
}
+static int check_image_fill_black(const AVPixFmtDescriptor *desc, enum
AVPixelFormat pix_fmt, int w, int h)
+{
+uint8_t *data[4];
+ptrdiff_t linesizes1[4];
+int ret, total_size, linesizes[4];
+
+ret = av_image_fill_linesizes(linesizes, pix_fmt, w);
+if (ret < 0)
+return ret;
+total_size = av_image_alloc(data, linesizes, w, h, pix_fmt, 4);
+if (total_size < 0) {
+printf("alloc failure");
+return total_size;
+}
+printf("total_size: %6d", total_size);
+if (desc->flags & AV_PIX_FMT_FLAG_PAL)
+total_size -= 256 * 4;
+// Make it non-black by default...
+memset(data[0], 0xA3, total_size);
+for (int i = 0; i < 4; i++)
+linesizes1[i] = linesizes[i];
+for (enum AVColorRange range = 0; range < AVCOL_RANGE_NB; range++) {
+ret = av_image_fill_black(data, linesizes1, pix_fmt, range, w, h);
+printf(", black_%s_crc: ", av_color_range_name(range));
+if (ret < 0) {
+printf("--");
+} else {
+const AVCRC *crc = av_crc_get_table(AV_CRC_32_IEEE_LE);
+printf("0x%08"PRIx32, av_crc(crc, 0, data[0], total_size));
+}
+}
+av_freep(&data[0]);
+
+return 0;
+}
+
int main(void)
{
-const AVPixFmtDescriptor *desc = NULL;
int64_t x, y;
for (y = -1; yflags & AV_PIX_FMT_FLAG_HWACCEL)
-continue;
-printf("%-16s", desc->name);
-check_image_fill(pix_fmt, w, h);
-printf("\n");
+if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
+continue;
+
+printf("%-16s", desc->name);
+if (i == 0)
+check_image_fill(pix_fmt, w, h);
+else
+check_image_fill_black(desc, pix_fmt, w, h);
+printf("\n");
+}
}
return 0;
diff --git a/tests/ref/fate/imgutils b/tests/ref/fate/imgutils
index f166cb67fb..f12bef3fb5 100644
--- a/tests/ref/fate/imgutils
+++ b/tests/ref/fate/imgutils
@@ -54,6 +54,7 @@
000
000
+image_fill tests
yuv420p planes: 3, linesizes: 64 32 32 0, plane_sizes: 3072
768 768 0, plane_offsets: 3072 768 0, total_size: 4608
yuyv422 planes: 1, linesizes: 128 0 0 0, plane_sizes: 6144
0 0 0, plane_offsets: 0 0 0, total_size: 6144
rgb24 planes: 1, linesizes: 192 0 0 0, plane_sizes: 9216
0 0 0, plane_offsets: 0 0 0, total_size: 9216
@@ -268,3 +269,219 @@ p412be planes: 2, linesizes: 128 256 0 0,
plane_sizes: 6144 12288
p412le planes: 2, linesizes: 128 256 0 0, plane_sizes: 6144
12288 0 0, plane_offsets: 6144 0 0, total_size: 18432
gbrap14be planes: 4, linesizes: 128 128 128 128, plane_sizes: 6144
6144 6144 6144, plane_offsets: 6144 6144 6144, total_size: 24576
gbrap14le planes: 4, linesizes: 128 128 128 128, plane_sizes: 6144
6144 6144 6144, plane_offsets: 6144 6144 6144, total_size: 24576
+
+image_fill_black tests
+yuv420p total_size: 4608, black_unknown_crc: 0xd00f6cc6,
black_tv_crc: 0xd00f6cc6, black_pc_crc: 0x234969af
+yuyv422 total_size: 6144, black_unknown_crc: 0xcb089fb0,
black_tv_crc: 0xcb089fb0, black_pc_crc: 0xc9dc3ddf
+rgb24 total_size: 9216, black_unknown_crc: 0x,
black_tv_crc: 0x, black_pc_crc: 0x
+bgr24 total_size: 9216, black_unknown_crc: 0x,
black_tv_crc: 0x, black_pc_crc: 0x
+yuv422p total_size: 6144, black_unknown_crc: 0x71fcc79c,
black_tv_crc: 0x71fcc79c, black_pc_crc: 0xa9fa0192
+yuv444p total_size: 9216, black_unknown_crc: 0x1c302b58,
black_tv_crc: 0x1c302b58, black_pc_crc: 0xdf792ea7
+yuv410p total_size: 3456, black_unknown_crc: 0x09f3e4b0,
black_tv_crc: 0x09f3e4b0, black_pc_crc: 0xe4f4e553
+yuv411p total_size: 4608, black_unknown_crc: 0xd00f6cc6,
black_tv_crc: 0xd00f6cc6, black_pc_crc: 0x234969af
+graytotal_size: 3072, black_unknown_crc: 0x63e301a2,
black_tv_crc: 0x63e301a2, black_pc_crc: 0x
+monow total_size:384, black_unknown_crc: 0x1
[FFmpeg-devel] [PATCH v2 1/7] avutil/tests/imgutils: factorize basic tests to new function
Signed-off-by: Marton Balint
---
libavutil/tests/imgutils.c | 68 ++
1 file changed, 39 insertions(+), 29 deletions(-)
diff --git a/libavutil/tests/imgutils.c b/libavutil/tests/imgutils.c
index 748bd6c9d2..1e2bb3fa01 100644
--- a/libavutil/tests/imgutils.c
+++ b/libavutil/tests/imgutils.c
@@ -19,6 +19,41 @@
#include "libavutil/imgutils.c"
#undef printf
+static int check_image_fill(enum AVPixelFormat pix_fmt, int w, int h) {
+uint8_t *data[4];
+size_t sizes[4];
+ptrdiff_t linesizes1[4], offsets[3] = { 0 };
+int i, total_size, linesizes[4];
+
+if (av_image_fill_linesizes(linesizes, pix_fmt, w) < 0)
+return -1;
+for (i = 0; i < 4; i++)
+linesizes1[i] = linesizes[i];
+if (av_image_fill_plane_sizes(sizes, pix_fmt, h, linesizes1) < 0)
+return -1;
+total_size = av_image_fill_pointers(data, pix_fmt, h, (void *)1,
linesizes);
+if (total_size < 0)
+return -1;
+for (i = 0; i < 4 && data[i]; i++);
+printf("planes: %d", i);
+// Test the output of av_image_fill_linesizes()
+printf(", linesizes:");
+for (i = 0; i < 4; i++)
+printf(" %3d", linesizes[i]);
+// Test the output of av_image_fill_plane_sizes()
+printf(", plane_sizes:");
+for (i = 0; i < 4; i++)
+printf(" %5"SIZE_SPECIFIER, sizes[i]);
+// Test the output of av_image_fill_pointers()
+for (i = 0; i < 3 && data[i + 1]; i++)
+offsets[i] = data[i + 1] - data[i];
+printf(", plane_offsets:");
+for (i = 0; i < 3; i++)
+printf(" %5"PTRDIFF_SPECIFIER, offsets[i]);
+printf(", total_size: %d", total_size);
+
+return 0;
+}
int main(void)
{
@@ -35,39 +70,14 @@ int main(void)
printf("\n");
while (desc = av_pix_fmt_desc_next(desc)) {
-uint8_t *data[4];
-size_t sizes[4];
-ptrdiff_t linesizes1[4], offsets[3] = { 0 };
-int i, total_size, w = 64, h = 48, linesizes[4];
+int w = 64, h = 48;
enum AVPixelFormat pix_fmt = av_pix_fmt_desc_get_id(desc);
-if (av_image_fill_linesizes(linesizes, pix_fmt, w) < 0)
-continue;
-for (i = 0; i < 4; i++)
-linesizes1[i] = linesizes[i];
-if (av_image_fill_plane_sizes(sizes, pix_fmt, h, linesizes1) < 0)
-continue;
-total_size = av_image_fill_pointers(data, pix_fmt, h, (void *)1,
linesizes);
-if (total_size < 0)
+if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
continue;
printf("%-16s", desc->name);
-for (i = 0; i < 4 && data[i]; i++);
-printf("planes: %d", i);
-// Test the output of av_image_fill_linesizes()
-printf(", linesizes:");
-for (i = 0; i < 4; i++)
-printf(" %3d", linesizes[i]);
-// Test the output of av_image_fill_plane_sizes()
-printf(", plane_sizes:");
-for (i = 0; i < 4; i++)
-printf(" %5"SIZE_SPECIFIER, sizes[i]);
-// Test the output of av_image_fill_pointers()
-for (i = 0; i < 3 && data[i + 1]; i++)
-offsets[i] = data[i + 1] - data[i];
-printf(", plane_offsets:");
-for (i = 0; i < 3; i++)
-printf(" %5"PTRDIFF_SPECIFIER, offsets[i]);
-printf(", total_size: %d\n", total_size);
+check_image_fill(pix_fmt, w, h);
+printf("\n");
}
return 0;
--
2.35.3
___
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".
