Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
Quoting Michael Niedermayer (2023-10-31 09:40:44) > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > > Section 7.4.4 of the MPEG-2 specifications requires that the > > last bit of the last coefficient be toggled so that the sum > > of all coefficients is odd; both our decoder and encoder > > did this only if the bitexact flag has been set (although > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > This patch changes this by removing the spec-incompliant > > functions. > > This commit message should include benchamarks documenting the speed loss > (of the unquantize, the IDCT and overall) > It is expected that the speed of some IDCTs will be impacted negativly > as the non zero terms will prevent the skiping of some significant code > > as well as information about how much PSNR improves (to the encoder input) > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > bitexactly > specified in MPEG-2 so one could think of this as a > correct implementation followed by a IDCT that was sometimes +-1 off > instead of spec non compliance > > Only after the benchmarks and PSNR is presented should we decide if this > is a change we want I disagree that the burden of proof should be on Andreas here. It should be up to whoever wants to keep this code to show that it is useful. -- 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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi Jianhui, On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < jianhui.j.dai-at-intel@ffmpeg.org> wrote: > The smaller delta patch to export the variable: > https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ > Personally, I prefer to limit the static data only in vp8.c. > Understood. It's going to be a dice-roll either way, and since I'm the maintainer, I get to pick :-). I prefer continuing with what we have in this version, but I'll leave it open for the majority opinion to overrule me for a few days before we merge this. Do you need me to merge or do you have commit access? If you adapt the cbs patch to use this (newly) exported table, I have no further review comments. 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] x86inc: Add REPX macro to repeat instructions/operations
Quoting Henrik Gramner via ffmpeg-devel (2023-10-01 19:55:57) > On Fri, Sep 29, 2023 at 1:38 PM Frank Plowman wrote: > > libavutil/x86/x86inc.asm | 10 ++ > > 1 file changed, 10 insertions(+) > > LGTM. pushed -- 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 v9 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
Hello,
On Wed, 8 Nov 2023, at 02:05, Tong Wu wrote:
> +/**
> + * @brief This struct is used to sync d3d12 execution
> + *
> + */
> +typedef struct AVD3D12VASyncContext {
> +/**
> + * D3D12 fence object
> + */
> +ID3D12Fence *fence;
> +
> +/**
> + * A handle to the event object
> + */
> +HANDLE event;
Sorry, but which event object? I would guess it's the ID3D12Fence::Signal, but
I'm not even sure.
I think this needs a bit more doc and explanations.
> +
> +/**
> + * The fence value used for sync
> + */
> +uint64_t fence_value;
> +} AVD3D12VASyncContext;
> +
> +/**
> + * @brief D3D12VA frame descriptor for pool allocation.
> + *
> + */
> +typedef struct AVD3D12VAFrame {
> +/**
> + * The texture in which the frame is located. The reference count
> is
> + * managed by the AVBufferRef, and destroying the reference will
> release
> + * the interface.
> + */
> +ID3D12Resource *texture;
> +
> +/**
> + * The index into the array texture element representing the frame
> + */
> +intptr_t index;
> +
> +/**
> + * The sync context for the texture
> + *
> + * Use av_d3d12va_wait_idle(sync_ctx) to ensure the decoding or
> encoding have been finised
> + * @see:
> https://learn.microsoft.com/en-us/windows/win32/medfound/direct3d-12-video-overview#directx-12-fences
> + */
> +AVD3D12VASyncContext *sync_ctx;
> +} AVD3D12VAFrame;
> +
> +/**
> + * @brief This struct is allocated as AVHWFramesContext.hwctx
> + *
> + */
> +typedef struct AVD3D12VAFramesContext {
> +/**
> + * This field is not able to be user-allocated at the present.
> + */
> +AVD3D12VAFrame *texture_infos;
> +} AVD3D12VAFramesContext;
> +
> +/**
> + * @brief Map sw pixel format to d3d12 format
> + *
> + * @return d3d12 specified format
> + */
> +DXGI_FORMAT av_d3d12va_map_sw_to_hw_format(enum AVPixelFormat pix_fmt);
> +
> +/**
> + * @brief Allocate an AVD3D12VASyncContext
> + *
> + * @return Error code (ret < 0 if failed)
> + */
> +int av_d3d12va_sync_context_alloc(AVD3D12VADeviceContext *ctx,
> AVD3D12VASyncContext **sync_ctx);
> +
> +/**
> + * @brief Free an AVD3D12VASyncContext
> + */
> +void av_d3d12va_sync_context_free(AVD3D12VASyncContext **sync_ctx);
> +
> +#endif /* AVUTIL_HWCONTEXT_D3D12VA_H */
> diff --git a/libavutil/hwcontext_d3d12va_internal.h
> b/libavutil/hwcontext_d3d12va_internal.h
> new file mode 100644
> index 00..bfd89b3545
> --- /dev/null
> +++ b/libavutil/hwcontext_d3d12va_internal.h
> @@ -0,0 +1,59 @@
> +/*
> + * Direct3D 12 HW acceleration.
> + *
> + * copyright (c) 2022-2023 Wu Jianhua
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#ifndef AVUTIL_HWCONTEXT_D3D12VA_INTERNAL_H
> +#define AVUTIL_HWCONTEXT_D3D12VA_INTERNAL_H
> +
> +/**
> + * @def COBJMACROS
> + *
> + * @brief Enable C style interface for D3D12
> + */
> +#ifndef COBJMACROS
> +#define COBJMACROS
> +#endif
> +
> +/**
> + * @def DX_CHECK
> + *
> + * @brief A check macro used by D3D12 functions highly frequently
> + */
> +#define DX_CHECK(hr) \
> +do { \
> +if (FAILED(hr)) \
> +goto fail;\
> +} while (0)
> +
> +/**
> + * @def D3D12_OBJECT_RELEASE
> + *
> + * @brief A release macro used by D3D12 objects highly frequently
> + */
> +#define D3D12_OBJECT_RELEASE(pInterface) \
> +do { \
> +if (pInterface) { \
> +IUnknown_Release((IUnknown *)pInterface); \
> +pInterface = NULL;\
> +} \
> +} while (0)
> +
> +#endif /* AVUTIL_HWCONTEXT_D3D12VA_INTERNAL_H */
> \ No newline at end of file
> diff --git a/libavutil/hwcontext_internal.h
> b/libavutil/hwcontext_internal.h
> index e6266494ac..4df516ee6a 100644
> --- a/libavutil/hwcontext_internal.h
> +++ b/libavutil/hwcontext_internal.h
> @@ -165,6 +165,7 @@ int ff_hwframe_map_replace(AVFrame *dst, const
> AVFrame *src);
>
> extern const HWContextType ff_hwcontext_type_cuda;
> extern
Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
Hi, On Wed, Nov 8, 2023 at 10:55 AM Ronald S. Bultje wrote: > Hi Jianhui, > > On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > >> The smaller delta patch to export the variable: >> https://patchwork.ffmpeg.org/project/ffmpeg/patch/dm6pr11mb268186349e600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ >> Personally, I prefer to limit the static data only in vp8.c. >> > > Understood. It's going to be a dice-roll either way, and since I'm the > maintainer, I get to pick :-). I prefer continuing with what we have in > this version, but I'll leave it open for the majority opinion to overrule > me for a few days before we merge this. > Actually, I realize that sounds quite rude, so let me elaborate: I prefer external data tables (in a separate source file from the rest of the code) because they tend to be big and clunky and you can't really change them anyway. They are essentially binary blob in numerical form. We use external data tables in quite a few parts of ffmpeg and I've grown accustomed to that design. For now, for old codecs where nothing much changes over time, I prefer to keep it as it is. Small diffs means easy to trace back when stuff breaks, as a general rule. But I admit that all this is personal preference. There's nothing wrong with a different approach, it's just that: different. Let's agree on a color (green!) and move on to shiny new objects. 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] libavformat: increase MAX_URL_SIZE
Quoting WooDzu (2023-10-28 15:04:38) > With the rise of object storage, like S3, it is not uncommon to generate > long pre-signed URLs. When a pre-signed URL is generated using a > short-lived credentials it may include a query parameter called > X-Amz-Security-Token that is 4kB on its own. > The current MAX_URL_SIZE will trim the URL with no any errors or > warnings and the request will fail with a http 400 error. Why do we have a static limit in the first place? Wouldn't it be better to make the relevant strings dynamically allocated? -- 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] avfilter/buffersrc: switch to activate
I have now been able to set up a reasonable test case with limit memoryuse 600M. Next step is to simplify the test case. (I cannot understand how you can pretend you analyzed the bug when your test case contains unrelated filters like hqdn3d or setsar.) -- 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/pgssubdec: Correct rendering of palette updates.
Sure. !40981: ffmpeg/incoming/00019.m2ts - multiplexed video and PG stream, courtesy of the author of !40981. !41826: ffmpeg/incoming/graphicplane_test.sup The behaviour observed on reference decoders is described in the associated text files. I updated the aggregate patch to fix a bug introduced in !40981, caught by graphicplane_test.sup: "Normal Case" object redefinition was broken. https://raw.githubusercontent.com/cubicibo/HandBrake/75ac11994fa4a32380d45c55a6add8344327773c/contrib/ffmpeg/A22-Add-cropping-and-graphic-plane-to-PGS-decoder.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] MAINTAINERS: add myself as a mediacodec and videotoolbox maintainer
tis 2023-11-07 klockan 11:19 +0800 skrev Zhao Zhili: > From: Zhao Zhili > > Signed-off-by: Zhao Zhili > --- > MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/MAINTAINERS b/MAINTAINERS > index b66c3d09a6..3430e1722b 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -268,11 +268,11 @@ Codecs: > Hardware acceleration: > dxva2* Hendrik Leppkes, Laurent > Aimar, Steve Lhomme > d3d11va* Steve Lhomme > - mediacodec* Matthieu Bouron, Aman Gupta > + mediacodec* Matthieu Bouron, Aman Gupta, > Zhao Zhili > vaapi* Haihao Xiang > vaapi_encode* Mark Thompson, Haihao Xiang > vdpau* Philip Langdale, Carl Eugen > Hoyos > - videotoolbox* Rick Kern, Aman Gupta > + videotoolbox* Rick Kern, Aman Gupta, Zhao > Zhili Sounds good to me /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] doc: add spi.txt
On 2023-10-16 00:49 +0200, Michael Niedermayer wrote: > This explains how to request refunds and what can be funded by SPI > > Co-Author: Stefano Sabatini > --- > doc/spi.txt | 73 + > 1 file changed, 73 insertions(+) > create mode 100644 doc/spi.txt > > diff --git a/doc/spi.txt b/doc/spi.txt > new file mode 100644 > index 00..ff4af8f42b > --- /dev/null > +++ b/doc/spi.txt > @@ -0,0 +1,73 @@ > +SPI (Software in the Public Interest) is a non-profit corporation > +registered in the state of New York founded to act as a fiscal sponsor > +for organizations that develop open source software and hardware. For > +details check here: > +https://www.spi-inc.org/ > + [...] > + > +Is it possible to fund active development by SPI: > +(the texts below have been taken from multiple > + replies FFmpeg has received from SPI, they have been edited > + so that "I" was replaced by "SPI" in some cases.) > +- > +Paying for development *does* require substantial > +additional paperwork, but it is not prohibited. > + > +Several SPI projects pay contractors for development > +efforts. SPI needs a contract in place which describes the work to be > +done. There are also various things SPI needs to check (e.g. are they a > +US person or not, as with GSoC mentor payments; are they really a > +contractor and not a employee). > + > +SPI can't deal with employment at the moment because that involves a > +lot of work, like health insurance, tax withholding, etc. Contractors > +are easier because they have to take care of that themselves; Whether > +someone is a contractor vs employee depends on various factors (that > +of course are different in every country) and can be disputed (see > +e.g. the debate about whether Uber drivers are employees); SPI has a > +questionnaire about their circumstances.) ^ Minor nit: Unbalanced parenthesis Can just be removed I read it correctly. Best regards, Alexander > +Unfortunately, there's no one-size-fits all when dealing with contractors. > +As already mentioned, without knowing the contributor's country > + > +SPI does have templates, but they depend on the contractors country. If it's > +US, Australia, France and a couple others SPI could provide them next day, > +otherwise SPI would need to ask their attorney to draft one, which would > +take some time > + > +Also, SPI has two models, MSA (which transfers ownership) and CSA (which > +grants a license instead). SPI usually sends the MSA (it's better for most > +purposes), but for development purposes, some projects prefer that the > +contractor retains ownership rights. > -- ___ ffmpeg-devel mailing list ffmpeg-devel@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 v9 1/9] libavutil: add hwcontext_d3d12va and AV_PIX_FMT_D3D12
Nov 8, 2023, 02:06 by tong1.wu-at-intel@ffmpeg.org: > From: Wu Jianhua <> toq...@outlook.com> > > > Signed-off-by: Wu Jianhua <> toq...@outlook.com> > > Signed-off-by: Tong Wu <> tong1...@intel.com> > > --- > configure | 5 + > doc/APIchanges | 7 + > libavutil/Makefile | 3 + > libavutil/hwcontext.c | 4 + > libavutil/hwcontext.h | 1 + > libavutil/hwcontext_d3d12va.c | 695 + > libavutil/hwcontext_d3d12va.h | 142 + > libavutil/hwcontext_d3d12va_internal.h | 59 +++ > libavutil/hwcontext_internal.h | 1 + > libavutil/pixdesc.c| 4 + > libavutil/pixfmt.h | 7 + > libavutil/tests/hwdevice.c | 2 + > libavutil/version.h| 2 +- > 13 files changed, 931 insertions(+), 1 deletion(-) > create mode 100644 libavutil/hwcontext_d3d12va.c > create mode 100644 libavutil/hwcontext_d3d12va.h > create mode 100644 libavutil/hwcontext_d3d12va_internal.h > > diff --git a/configure b/configure > index 8ab658f730..69d7a48280 100755 > --- a/configure > +++ b/configure > @@ -334,6 +334,7 @@ External library support: > --disable-cuda-llvm disable CUDA compilation using clang [autodetect] > --disable-cuvid disable Nvidia CUVID support [autodetect] > --disable-d3d11vadisable Microsoft Direct3D 11 video acceleration > code [autodetect] > + --disable-d3d12vadisable Microsoft Direct3D 12 video acceleration > code [autodetect] > --disable-dxva2 disable Microsoft DirectX 9 video acceleration code > [autodetect] > --disable-ffnvcodec disable dynamically linked Nvidia code [autodetect] > --enable-libdrm enable DRM code (Linux) [no] > @@ -1922,6 +1923,7 @@ HWACCEL_AUTODETECT_LIBRARY_LIST=" > cuda_llvm > cuvid > d3d11va > +d3d12va > dxva2 > ffnvcodec > nvdec > @@ -3041,6 +3043,7 @@ crystalhd_deps="libcrystalhd_libcrystalhd_if_h" > cuda_deps="ffnvcodec" > cuvid_deps="ffnvcodec" > d3d11va_deps="dxva_h ID3D11VideoDecoder ID3D11VideoContext" > +d3d12va_deps="dxva_h ID3D12Device ID3D12VideoDecoder" > dxva2_deps="dxva2api_h DXVA2_ConfigPictureDecode ole32 user32" > ffnvcodec_deps_any="libdl LoadLibrary" > mediacodec_deps="android" > @@ -6563,6 +6566,8 @@ check_type "windows.h dxgi1_2.h" "IDXGIOutput1" > check_type "windows.h dxgi1_5.h" "IDXGIOutput5" > check_type "windows.h d3d11.h" "ID3D11VideoDecoder" > check_type "windows.h d3d11.h" "ID3D11VideoContext" > +check_type "windows.h d3d12.h" "ID3D12Device" > +check_type "windows.h d3d12video.h" "ID3D12VideoDecoder" > check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00 > check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 > check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat > diff --git a/doc/APIchanges b/doc/APIchanges > index d4511ce2dd..2e71943b34 100644 > --- a/doc/APIchanges > +++ b/doc/APIchanges > @@ -2,6 +2,13 @@ The last version increases of all libraries were on > 2023-02-09 > > API changes, most recent first: > > +2023-11-07 - xx - lavu 58.32.100 - pixfmt.h hwcontext.h > hwcontext_d3d12va.h > + Add AV_HWDEVICE_TYPE_D3D12VA and AV_PIX_FMT_D3D12. > + Add AVD3D12VADeviceContext, AVD3D12VASyncContext, AVD3D12VAFrame and > + AVD3D12VAFramesContext. > + Add av_d3d12va_map_sw_to_hw_format, av_d3d12va_sync_context_alloc, > + av_d3d12va_sync_context_free. > + > 2023-10-31 - xx - lavu 58.31.100 - pixdesc.h > Add AV_PIX_FMT_FLAG_XYZ. > > diff --git a/libavutil/Makefile b/libavutil/Makefile > index 4711f8cde8..6a8566f1d9 100644 > --- a/libavutil/Makefile > +++ b/libavutil/Makefile > @@ -42,6 +42,7 @@ HEADERS = adler32.h > \ > hwcontext.h \ > hwcontext_cuda.h \ > hwcontext_d3d11va.h \ > + hwcontext_d3d12va.h \ > hwcontext_drm.h \ > hwcontext_dxva2.h \ > hwcontext_qsv.h \ > @@ -190,6 +191,7 @@ OBJS = adler32.o > \ > > OBJS-$(CONFIG_CUDA) += hwcontext_cuda.o > OBJS-$(CONFIG_D3D11VA) += hwcontext_d3d11va.o > +OBJS-$(CONFIG_D3D12VA) += hwcontext_d3d12va.o > OBJS-$(CONFIG_DXVA2)+= hwcontext_dxva2.o > OBJS-$(CONFIG_LIBDRM) += hwcontext_drm.o > OBJS-$(CONFIG_MACOS_KPERF) += macos_kperf.o > @@ -213,6 +215,7 @@ SKIPHEADERS-$(HAVE_CUDA_H) += hwcontext_cuda.h > SKIPHEADERS-$(CONFIG_CUDA) += hwcontext_cuda_internal.h \ > cuda_check.h > SKIPHEADERS-$(CONFIG_D3D11VA) +=
Re: [FFmpeg-devel] [PATCH] lavc/pgssubdec: Correct rendering of palette updates.
On Wed, Nov 8, 2023 at 6:07 PM cubicibo cubicibo wrote: > Sure. > !40981: ffmpeg/incoming/00019.m2ts - multiplexed video and PG stream, > courtesy of the author of !40981. > !41826: ffmpeg/incoming/graphicplane_test.sup > Does those have direct links now? The behaviour observed on reference decoders is described in the associated > text files. > > I updated the aggregate patch to fix a bug introduced in !40981, caught by > graphicplane_test.sup: "Normal Case" object redefinition was broken. > > https://raw.githubusercontent.com/cubicibo/HandBrake/75ac11994fa4a32380d45c55a6add8344327773c/contrib/ffmpeg/A22-Add-cropping-and-graphic-plane-to-PGS-decoder.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". > ___ ffmpeg-devel mailing list ffmpeg-devel@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/buffersrc: switch to activate
On Wed, Nov 8, 2023 at 5:53 PM Nicolas George wrote: > I have now been able to set up a reasonable test case with limit > memoryuse 600M. Next step is to simplify the test case. > > (I cannot understand how you can pretend you analyzed the bug when your > test case contains unrelated filters like hqdn3d or setsar.) > I did. I simplified it right from start. But I kept it for myself as It is not really relevant. With this pace of your debugging it can be expected that universe will froze first before you manage to came to any conclusion about the "framework". > -- > 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".
Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: switch to activate
Paul B Mahol (12023-11-08): > I did. I simplified it right from start. But I kept it for myself as It is > not really relevant. It is very relevant for reproducing the problem and reviewing the patch. Please show what you have, it will save time. > With this pace of your debugging it can be expected that universe will > froze first before you manage to came to any conclusion about the > "framework". Then work on something else. There is no urgency here. -- 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] lavc/pgssubdec: Correct rendering of palette updates.
My bad. Append .txt to the URLs to get the matching test description. !40981: https://streams.videolan.org/ffmpeg/incoming/00019.m2ts !41826: https://streams.videolan.org/ffmpeg/incoming/graphicplane_test.sup ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] lavc/aacpsdsp: rework R-V V hybrid_synthesis_deint
Given the size of the data set, strided memory accesses cannot be avoided.
We can still do better than the current code.
ps_hybrid_synthesis_deint_c: 12065.5
ps_hybrid_synthesis_deint_rvv_i32: 13650.2 (before)
ps_hybrid_synthesis_deint_rvv_i64: 8181.0 (after)
---
libavcodec/riscv/aacpsdsp_init.c | 8 ++---
libavcodec/riscv/aacpsdsp_rvv.S | 61 +---
2 files changed, 36 insertions(+), 33 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_init.c b/libavcodec/riscv/aacpsdsp_init.c
index f72d1bc330..e094660cf3 100644
--- a/libavcodec/riscv/aacpsdsp_init.c
+++ b/libavcodec/riscv/aacpsdsp_init.c
@@ -46,16 +46,16 @@ av_cold void ff_psdsp_init_riscv(PSDSPContext *c)
c->hybrid_analysis = ff_ps_hybrid_analysis_rvv;
if (flags & AV_CPU_FLAG_RVB_ADDR) {
-if (flags & AV_CPU_FLAG_RVV_I64)
+if (flags & AV_CPU_FLAG_RVV_I64) {
c->add_squares = ff_ps_add_squares_rvv;
+c->hybrid_synthesis_deint = ff_ps_hybrid_synthesis_deint_rvv;
+}
c->mul_pair_single = ff_ps_mul_pair_single_rvv;
c->stereo_interpolate[0] = ff_ps_stereo_interpolate_rvv;
}
}
-if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
+if ((flags & AV_CPU_FLAG_RVV_I32) && (flags & AV_CPU_FLAG_RVB_ADDR))
c->hybrid_analysis_ileave = ff_ps_hybrid_analysis_ileave_rvv;
-c->hybrid_synthesis_deint = ff_ps_hybrid_synthesis_deint_rvv;
-}
#endif
}
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index cf872599c8..1dc426e01c 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/riscv/aacpsdsp_rvv.S
@@ -190,38 +190,41 @@ func ff_ps_hybrid_analysis_ileave_rvv, zve32x /* no needs
for zve32f here */
ret
endfunc
-func ff_ps_hybrid_synthesis_deint_rvv, zve32x
-sllit1, a2, 5 + 1 + 2
-sh2add a0, a2, a0
-add a1, a1, t1
-addia2, a2, -64
-li t1, 38 * 64 * 4
-li t6, 64 * 4
-add a4, a0, t1
-beqza2, 3f
+func ff_ps_hybrid_synthesis_deint_rvv, zve64x
+sllit0, a2, 5 + 1 + 2
+sh2add a0, a2, a0
+add a1, a1, t0
+addit2, a2, -64
+li t0, 38 * 64
+li t1, 32 * 2 * 4
+li t4, 8 - 16384 // offset from in[64][n][0] to in[0][n + 1][0]
+sllit5, a2, 5 + 1 + 2 // and from in[0][n+1][0] to in[0][n+1][s]
+neg t2, t2
+li t3, 32
+add a4, t4, t5
+sh2add t0, t0, a0
1:
-mv t0, a0
-mv t1, a1
-mv t3, a3
-mv t4, a4
-addia2, a2, 1
+mv t4, t2
+addia3, a3, -1
2:
-vsetvli t5, t3, e32, m4, ta, ma
-vlseg2e32.v v16, (t1)
-sub t3, t3, t5
-vsse32.vv16, (t0), t6
-mul t2, t5, t6
-vsse32.vv20, (t4), t6
-sh3add t1, t5, t1
-add t0, t0, t2
-add t4, t4, t2
-bnezt3, 2b
+vsetvli t5, t4, e32, m4, ta, ma
+vlse64.v v16, (a1), t1 /* sizeof (float[32][2]) */
+sub t4, t4, t5
+vnsrl.wx v24, v16, zero
+sllit6, t5, 5 + 1 + 2
+vnsrl.wx v28, v16, t3 /* 32 */
+add a1, a1, t6
+vse32.v v24, (a0)
+sh2add a0, t5, a0
+vse32.v v28, (t0)
+sh2add t0, t5, t0
+bnezt4, 2b
+
+add a1, a1, a4
+sh2add a0, a2, a0
+sh2add t0, a2, t0
+bneza3, 1b
-add a0, a0, 4
-add a1, a1, 32 * 2 * 4
-add a4, a4, 4
-bneza2, 1b
-3:
ret
endfunc
--
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 1/2] lavc/aacpsdsp: rework R-V V add_squares
Segmented loads may be slower than not. So this advantageously uses a
unit-strided load and narrowing shifts instead.
Before:
ps_add_squares_c: 60757.7
ps_add_squares_rvv_f32: 22242.5
After:
ps_add_squares_c: 60516.0
ps_add_squares_rvv_i64: 17067.7
---
libavcodec/riscv/aacpsdsp_init.c | 3 ++-
libavcodec/riscv/aacpsdsp_rvv.S | 9 ++---
2 files changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/riscv/aacpsdsp_init.c b/libavcodec/riscv/aacpsdsp_init.c
index c5ec796232..f72d1bc330 100644
--- a/libavcodec/riscv/aacpsdsp_init.c
+++ b/libavcodec/riscv/aacpsdsp_init.c
@@ -46,7 +46,8 @@ av_cold void ff_psdsp_init_riscv(PSDSPContext *c)
c->hybrid_analysis = ff_ps_hybrid_analysis_rvv;
if (flags & AV_CPU_FLAG_RVB_ADDR) {
-c->add_squares = ff_ps_add_squares_rvv;
+if (flags & AV_CPU_FLAG_RVV_I64)
+c->add_squares = ff_ps_add_squares_rvv;
c->mul_pair_single = ff_ps_mul_pair_single_rvv;
c->stereo_interpolate[0] = ff_ps_stereo_interpolate_rvv;
}
diff --git a/libavcodec/riscv/aacpsdsp_rvv.S b/libavcodec/riscv/aacpsdsp_rvv.S
index fe250cd83b..cf872599c8 100644
--- a/libavcodec/riscv/aacpsdsp_rvv.S
+++ b/libavcodec/riscv/aacpsdsp_rvv.S
@@ -1,5 +1,5 @@
/*
- * Copyright © 2022 Rémi Denis-Courmont.
+ * Copyright © 2022-2023 Rémi Denis-Courmont.
*
* This file is part of FFmpeg.
*
@@ -20,13 +20,16 @@
#include "libavutil/riscv/asm.S"
-func ff_ps_add_squares_rvv, zve32f
+func ff_ps_add_squares_rvv, zve64f
+li t1, 32
1:
vsetvli t0, a2, e32, m4, ta, ma
-vlseg2e32.v v24, (a1)
+vle64.v v8, (a1)
sub a2, a2, t0
+vnsrl.wxv24, v8, zero
vle32.v v16, (a0)
sh3add a1, t0, a1
+vnsrl.wxv28, v8, t1
vfmacc.vv v16, v24, v24
vfmacc.vv v16, v28, v28
vse32.v v16, (a0)
--
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] lavc/sbrdsp: R-V V autocorrelate
With 5 accumulator vectors and 6 inputs, this can only use LMUL=2.
Also the number of vector loop iterations is small, just 5 on 128-bit
vector hardware.
The vector loop is somewhat unusual in that it processes data in
descending memory order, in order to save on vector slides:
in descending order, we can extract elements to carry over to the next
iteration from the bottom of the vectors directly. With ascending order
(see in the Opus postfilter function), there are no ways to get the top
elements directly. On the downside, this requires the use of separate
shift and sub (the would-be SH3SUB instruction does not exist), with
a small pipeline stall on the vector load address.
The edge cases in scalar are done in scalar as this saves on loads
and remains significantly faster than C.
autocorrelate_c: 669.2
autocorrelate_rvv_f32: 421.0
---
libavcodec/riscv/sbrdsp_init.c | 12 +++--
libavcodec/riscv/sbrdsp_rvv.S | 89 ++
2 files changed, 97 insertions(+), 4 deletions(-)
diff --git a/libavcodec/riscv/sbrdsp_init.c b/libavcodec/riscv/sbrdsp_init.c
index 71de681185..c1ed5b639c 100644
--- a/libavcodec/riscv/sbrdsp_init.c
+++ b/libavcodec/riscv/sbrdsp_init.c
@@ -26,6 +26,7 @@
void ff_sbr_sum64x5_rvv(float *z);
float ff_sbr_sum_square_rvv(float (*x)[2], int n);
void ff_sbr_neg_odd_64_rvv(float *x);
+void ff_sbr_autocorrelate_rvv(const float x[40][2], float phi[3][2][2]);
void ff_sbr_hf_g_filt_rvv(float (*Y)[2], const float (*X_high)[40][2],
const float *g_filt, int m_max, intptr_t ixh);
@@ -34,10 +35,13 @@ av_cold void ff_sbrdsp_init_riscv(SBRDSPContext *c)
#if HAVE_RVV
int flags = av_get_cpu_flags();
-if ((flags & AV_CPU_FLAG_RVV_F32) && (flags & AV_CPU_FLAG_RVB_ADDR)) {
-c->sum64x5 = ff_sbr_sum64x5_rvv;
-c->sum_square = ff_sbr_sum_square_rvv;
-c->hf_g_filt = ff_sbr_hf_g_filt_rvv;
+if (flags & AV_CPU_FLAG_RVV_F32) {
+if (flags & AV_CPU_FLAG_RVB_ADDR) {
+c->sum64x5 = ff_sbr_sum64x5_rvv;
+c->sum_square = ff_sbr_sum_square_rvv;
+c->hf_g_filt = ff_sbr_hf_g_filt_rvv;
+}
+c->autocorrelate = ff_sbr_autocorrelate_rvv;
}
#if __riscv_xlen >= 64
if ((flags & AV_CPU_FLAG_RVV_I64) && (flags & AV_CPU_FLAG_RVB_ADDR))
diff --git a/libavcodec/riscv/sbrdsp_rvv.S b/libavcodec/riscv/sbrdsp_rvv.S
index 932a5dd7d1..2f3a0969d7 100644
--- a/libavcodec/riscv/sbrdsp_rvv.S
+++ b/libavcodec/riscv/sbrdsp_rvv.S
@@ -85,6 +85,95 @@ func ff_sbr_neg_odd_64_rvv, zve64x
endfunc
#endif
+func ff_sbr_autocorrelate_rvv, zve32f
+vsetvli t0, zero, e32, m4, ta, ma
+vmv.v.x v0, zero
+flw fa0, (a0)
+vmv.v.x v4, zero
+flw fa1, 4(a0)
+vmv.v.x v8, zero
+flw fa2, 8(a0)
+li a2, 37
+flw fa3, 12(a0)
+fmul.s ft10, fa0, fa0
+flw fa4, 16(a0)
+fmul.s ft6, fa0, fa2
+flw fa5, 20(a0)
+addia0, a0, 38 * 8
+fmul.s ft7, fa0, fa3
+fmul.s ft2, fa0, fa4
+fmul.s ft3, fa0, fa5
+flw fa0, (a0)
+fmadd.s ft10, fa1, fa1, ft10
+fmadd.s ft6, fa1, fa3, ft6
+flw fa3, 12(a0)
+fnmsub.s ft7, fa1, fa2, ft7
+flw fa2, 8(a0)
+fmadd.s ft2, fa1, fa5, ft2
+fnmsub.s ft3, fa1, fa4, ft3
+flw fa1, 4(a0)
+fmul.s ft4, fa0, fa0
+fmul.s ft0, fa0, fa2
+fmul.s ft1, fa0, fa3
+fmadd.s ft4, fa1, fa1, ft4
+fmadd.s ft0, fa1, fa3, ft0
+fnmsub.s ft1, fa1, fa2, ft1
+1:
+vsetvli t0, a2, e32, m2, tu, ma
+sllit1, t0, 3
+sub a0, a0, t1
+vlseg2e32.v v16, (a0)
+sub a2, a2, t0
+vfmacc.vv v0, v16, v16
+vfslide1down.vf v20, v16, fa0
+vfmacc.vv v4, v16, v20
+vfslide1down.vf v22, v18, fa1
+vfmacc.vv v0, v18, v18
+vfslide1down.vf v24, v20, fa2
+vfmacc.vv v4, v18, v22
+vfslide1down.vf v26, v22, fa3
+vfmacc.vv v6, v16, v22
+vfmv.f.s fa0, v16
+vfmacc.vv v8, v16, v24
+vfmv.f.s fa1, v18
+vfmacc.vv v10, v16, v26
+vfmv.f.s fa2, v20
+vfnmsac.vv v6, v18, v20
+vfmv.f.s fa3, v22
+vfmacc.vv v8, v18, v26
+vfnmsac.vv v10, v18, v24
+bneza2, 1b
+
+vsetvli t0, zero, e32, m2, ta, ma
+vfredusum.vs v0, v0, v2
+vfredusum.vs v4, v4, v2
+vfmv.f.s fa0, v0
+vfredusum.vs v6, v6, v2
+vfmv.f.s fa2, v4
+fadd.s ft4, ft4, fa0
+vfredusum.vs v8, v8, v2
+vfmv.f.s fa3, v6
+fadd.s ft0, ft0, fa2
+vfredusum.vs v10, v10, v2
+vfmv.f.s fa4, v8
+fadd.s ft1, ft1, fa3
+vfmv.f.s fa5, v10
+fsw ft0, (a1)
+fadd.s ft2, ft2, fa4
+fsw ft1, 4(a1)
+fadd.s ft3, ft3, fa5
+fsw ft2, 8(a1)
+fadd.s ft6, ft
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
On 2023-11-08 12:40 +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2023-10-31 09:40:44) > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > last bit of the last coefficient be toggled so that the sum > > > of all coefficients is odd; both our decoder and encoder > > > did this only if the bitexact flag has been set (although > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > This patch changes this by removing the spec-incompliant > > > functions. > > > > This commit message should include benchamarks documenting the speed loss > > (of the unquantize, the IDCT and overall) > > It is expected that the speed of some IDCTs will be impacted negativly > > as the non zero terms will prevent the skiping of some significant code > > > > as well as information about how much PSNR improves (to the encoder input) > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > > bitexactly > > specified in MPEG-2 so one could think of this as a > > correct implementation followed by a IDCT that was sometimes +-1 off > > instead of spec non compliance > > > > Only after the benchmarks and PSNR is presented should we decide if this > > is a change we want > > I disagree that the burden of proof should be on Andreas here. It should > be up to whoever wants to keep this code to show that it is useful. There was an argument presented. That argument could be challenged or otherwise explained why it more important to have this always behave like with bitexact. This could lead to "OK, I think removal is better" or if not benchmarks could lead to one or the other decision. Saying the burden is on whoever wants to keep the code sounds like a way for arbitrary code removal. While I agree getting rid of code can be a good thing, this would definitely take it too far. Best regards, Alexander ___ ffmpeg-devel mailing list ffmpeg-devel@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] doc/html: Support texinfo 7.0
On date Wednesday 2023-11-08 16:53:27 +, Frank Plowman wrote: > Patches attached. > > Changes since v2: * Split changes to t2h.pm and bootstrap.min.css into > separate commits. * Add justification for CSS changes to commit message. Thanks, both applied. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/mpegvideo: Remove spec-incompliant inverse quantisation
On Wed, Nov 8, 2023 at 3:46 PM Alexander Strasser wrote: > On 2023-11-08 12:40 +0100, Anton Khirnov wrote: > > Quoting Michael Niedermayer (2023-10-31 09:40:44) > > > On Mon, Oct 30, 2023 at 02:11:27PM +0100, Andreas Rheinhardt wrote: > > > > Section 7.4.4 of the MPEG-2 specifications requires that the > > > > last bit of the last coefficient be toggled so that the sum > > > > of all coefficients is odd; both our decoder and encoder > > > > did this only if the bitexact flag has been set (although > > > > stuff like this should be behind AV_CODEC_FLAG2_FAST). > > > > This patch changes this by removing the spec-incompliant > > > > functions. > > > > > > This commit message should include benchamarks documenting the speed > loss > > > (of the unquantize, the IDCT and overall) > > > It is expected that the speed of some IDCTs will be impacted negativly > > > as the non zero terms will prevent the skiping of some significant code > > > > > > as well as information about how much PSNR improves (to the encoder > input) > > > > > > Also the change is a +-1 in one spot before the IDCT, the IDCT is not > bitexactly > > > specified in MPEG-2 so one could think of this as a > > > correct implementation followed by a IDCT that was sometimes +-1 off > > > instead of spec non compliance > > > > > > Only after the benchmarks and PSNR is presented should we decide if > this > > > is a change we want > > > > I disagree that the burden of proof should be on Andreas here. It should > > be up to whoever wants to keep this code to show that it is useful. > > There was an argument presented. > > That argument could be challenged or otherwise explained why it more > important to have this always behave like with bitexact. > > This could lead to "OK, I think removal is better" or if not benchmarks > could lead to one or the other decision. > > Saying the burden is on whoever wants to keep the code sounds like a way > for arbitrary code removal. While I agree getting rid of code can be a good > thing, this would definitely take it too far. > To be fair, this is noncompliant spec code, it shouldn't be present at all since it produces inconsistent results (with the spec) and there is no device particularly needing this functionality.It's not arbitrary code removal, it's removing something that is not needed any more since the speed impact (pro or against) is negligible on modern computers. I'm of the opinion that presenting an argument against such a targeted and specific code removal with no supportive use case should be noted but not acted upon, until relevant proof is brought over. Yes sadly that burden should fall on whoever is presenting the argument. -- 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] doc/html: Support texinfo 7.0
On date Wednesday 2023-11-08 23:56:46 +0100, Stefano Sabatini wrote: > On date Wednesday 2023-11-08 16:53:27 +, Frank Plowman wrote: > > Patches attached. > > > > Changes since v2: * Split changes to t2h.pm and bootstrap.min.css into > > separate commits. * Add justification for CSS changes to commit message. > > Thanks, both applied. For clarification, they were applied to master. Where should they be backported? (not sure 6.1 branch was already created). ___ ffmpeg-devel mailing list ffmpeg-devel@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 issues today
Hi At around 8 o clock today there was heavy load on gitweb from the following IP ranges 27.44.204.*|27.44.125.*|27.44.122.*|14.17.95.*|14.17.85.*|120.233.114.*|120.233.118.* This caused eventually some process from our mail handling pipeline to be killed and not automatically restarting. Ive restarted the affected process once i noticed this a few hours ago. ATM it seems some mails are still missing, i hope they will all appear within the next day or so If any server admins have seen similar, then suggestions to harden apache and gitweb are welcome. The user agent fields on these requests looked normal And because these came from many IP ranges our per IP limit in mod_qos did not stop it adequently 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] doc/html: Support texinfo 7.0
On Wed, Nov 08, 2023 at 11:59:48PM +0100, Stefano Sabatini wrote: > On date Wednesday 2023-11-08 23:56:46 +0100, Stefano Sabatini wrote: > > On date Wednesday 2023-11-08 16:53:27 +, Frank Plowman wrote: > > > Patches attached. > > > > > > Changes since v2: * Split changes to t2h.pm and bootstrap.min.css into > > > separate commits. * Add justification for CSS changes to commit message. > > > > Thanks, both applied. > > For clarification, they were applied to master. > > Where should they be backported? (not sure 6.1 branch was already > created). I just backported it locally to all branches between 3.4 and 6.1 3.4 to 4.4 needed 2 more patches :) normally backports should be to all maintained branches (excluding anything thats too hard and excluding anything where the risk of regressions exceeds the gain) I did it here as i want to make releases of 5.1/6.0 soonish thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] fftools/ffplay: use SDL_WaitEvent instead of SDL_PeepEvents while paused
On Tue, Nov 07, 2023 at 08:57:57PM +, Bolshoy Toster wrote:
> Currently, when ffplay is paused, it still constantly polls for events at
> the
> REFRESH_RATE (100 times per second). This leads to a high (5-10% on the
> latest
> commit, using SDL2 2.28.5-1) CPU usage, when it should be idle.
>
> This commit changes this behavior to use SDL_WaitEvent while paused,
> allowing
> ffplay to use less (0-5% under X11) CPU time while paused on supported
> platforms
> (windows, X11 and wayland) with SDL versions >=2.0.16.
>
> This has the side effect of only running the refresh loop when there's an
> event,
> preventing the cursor from being hidden while paused.
>
> Signed-off-by: bolshoytoster
> ---
> fftools/ffplay.c | 31 ---
> 1 file changed, 20 insertions(+), 11 deletions(-)
>
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index d8c69e1..7814589 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -3221,20 +3221,29 @@ static void toggle_audio_display(VideoState *is)
> }
> }
> +static void refresh(VideoState *is, double *remaining_time) {
> +if (!cursor_hidden && av_gettime_relative() - cursor_last_shown >
> CURSOR_HIDE_DELAY) {
> +SDL_ShowCursor(0);
patch corupted by line breaks
Applying: fftools/ffplay: use SDL_WaitEvent instead of SDL_PeepEvents while
paused
error: corrupt patch at line 50
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"I am not trying to be anyone's saviour, I'm trying to think about the
future and not be sad" - Elon Musk
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/4] avformat/hlsenc: Add init_program_date_time so start time can be specified
On Sun, Nov 5, 2023 at 1:21 AM Marton Balint wrote:
>
>
> On Fri, 27 Oct 2023, David Johansen wrote:
>
> > On Fri, Oct 27, 2023 at 4:58 AM wrote:
> >
> >> On 27 Oct 2023, at 5:59, Dave Johansen wrote:
> >> > @item second_level_segment_index
> >> > Makes it possible to use segment indexes as %%d in
> hls_segment_filename
> >> expression
> >> > besides date/time values when strftime is on.
> >> > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> >> > index 4ef84c05c1..5dfff6b2b6 100644
> >> > --- a/libavformat/hlsenc.c
> >> > +++ b/libavformat/hlsenc.c
> >> > @@ -212,6 +212,8 @@ typedef struct HLSContext {
> >> > int64_t recording_time;
> >> > int64_t max_seg_size; // every segment file max size
> >> >
> >> > +char *init_program_date_time;
> >> > +
> >> > char *baseurl;
> >> > char *vtt_format_options_str;
> >> > char *subtitle_filename;
> >> > @@ -1192,6 +1194,25 @@ static int hls_append_segment(struct
> >> AVFormatContext *s, HLSContext *hls,
> >> > return 0;
> >> > }
> >> >
> >> > +static double parse_iso8601(const char *ptr) {
>
> Please use the existing function av_parse_time(). That can more completely
> handle ISO8601 and even more.
>
I made a patch for this an submitted it with --in-reply-to with the Message
ID from this email, but it doesn't appear that it linked it to the existing
patches I sent. What's the proper way that I should submit follow on
patches like this in the future?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote: > David Johansen 于2023年10月27日周五 12:03写道： > > > > > > > > LGTM > > > > > > > > > Thanks > > > Steven > > > > > > > I'm new to ffmpeg development so what's the process for this to be > merged? > > Do I need to do something or is it taken care of by a different > > process/someone else? > > Nothing, just leave enough time for more developers review, and will > push this if no more comments. > Don't worry David, this is valuable patch, you did a great job. > I submitted a handful of patches and I believe I've addressed all of the feedback I've seen, so is there anything I need to do to follow up on them and get them merged? Thanks, Dave ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Add CHANNELS to EXT-X-MEDIA for Audio
David Johansen 于2023年11月9日周四 07:47写道： > > On Fri, Oct 27, 2023 at 1:33 AM Steven Liu wrote: > > > David Johansen 于2023年10月27日周五 12:03写道： > > > > > > > > > > > LGTM > > > > > > > > > > > > Thanks > > > > Steven > > > > > > > > > > I'm new to ffmpeg development so what's the process for this to be > > merged? > > > Do I need to do something or is it taken care of by a different > > > process/someone else? > > > > Nothing, just leave enough time for more developers review, and will > > push this if no more comments. > > Don't worry David, this is valuable patch, you did a great job. > > > > I submitted a handful of patches and I believe I've addressed all of > the feedback I've seen, so is there anything I need to do to follow up on > them and get them merged? Will apply this patch after 24 hours if there have no more comments. > > Thanks, > Dave 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 v5] avcodec/cbs_vp8: Add support for VP8 codec bitstream
> -Original Message- > From: ffmpeg-devel On Behalf Of Ronald S. > Bultje > Sent: Thursday, November 9, 2023 12:38 AM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH v5] avcodec/cbs_vp8: Add support for VP8 > codec bitstream > > Hi, > > On Wed, Nov 8, 2023 at 10:55 AM Ronald S. Bultje wrote: > > > Hi Jianhui, > > > > On Tue, Nov 7, 2023 at 8:52 PM Dai, Jianhui J < > > jianhui.j.dai-at-intel@ffmpeg.org> wrote: > > > >> The smaller delta patch to export the variable: > >> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/DM6PR11MB268186349E > >> 600824e1577dfdb1...@dm6pr11mb2681.namprd11.prod.outlook.com/ > >> Personally, I prefer to limit the static data only in vp8.c. > >> > > > > Understood. It's going to be a dice-roll either way, and since I'm the > > maintainer, I get to pick :-). I prefer continuing with what we have > > in this version, but I'll leave it open for the majority opinion to > > overrule me for a few days before we merge this. > > > > Actually, I realize that sounds quite rude, so let me elaborate: I prefer > external > data tables (in a separate source file from the rest of the code) because > they tend > to be big and clunky and you can't really change them anyway. They are > essentially binary blob in numerical form. We use external data tables in > quite a > few parts of ffmpeg and I've grown accustomed to that design. For now, for old > codecs where nothing much changes over time, I prefer to keep it as it is. > Small > diffs means easy to trace back when stuff breaks, as a general rule. > > But I admit that all this is personal preference. There's nothing wrong with a > different approach, it's just that: different. Let's agree on a color > (green!) and > move on to shiny new objects. I fully respect all of the feedback provided during the code review. Thank you for your patience. : ) I don’t have the commit access. Appreciate to help to submit if everything goes well. > > 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".
