Re: [FFmpeg-devel] Is the GA democratic ?

On Tue, Jan 21, 2025 at 5:42 PM Michael Niedermayer wrote: > > Hi > > As people likely know i belive it is not but i got a 2nd opinion: Hi Michael, Can you ask ChatGPT the following: Is it ok for one person to be in control of a major open source project when they promised to step down? Can you

Re: [FFmpeg-devel] Is the GA democratic ?

On Tue, 21 Jan 2025, 18:57 James Almer, wrote: > On 1/21/2025 3:13 PM, Kieran Kunhya via ffmpeg-devel wrote: > > On Tue, Jan 21, 2025 at 5:42 PM Michael Niedermayer > > wrote: > >> > >> Hi > >> > >> As people likely know i belive it

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Wed, Jan 22, 2025 at 4:37 PM Michael Niedermayer wrote: > > Hi > > On Mon, Jan 20, 2025 at 03:00:17PM +, Kieran Kunhya via ffmpeg-devel > wrote: > [...] > > > Error recovery protocols are complicated - > > everything is complicated > > > > this

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> Can you please stop this "my way or no way" The irony is not lost on me of this sentence (from the person banning people, censoring people, creating paranoid theories about the GA). Kieran ___ ffmpeg-devel mailing list [email protected] https://

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: Be more picky on extensions

On Wed, 22 Jan 2025, 20:36 Michael Niedermayer, wrote: > This blocks disallowed extensions from probing > It also requires all available segments to have matching extensions to the > format > mpegts is treated independent of the extension > Potentially this is a stupid question but what stops an

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Thu, Jan 16, 2025 at 8:15 PM Romain Beauxis wrote: > > This patch implements the decoding logic for the FEC error- > correction method described in the Pro-MPEG CoP #3-R2 FEC[1] > > We are still in the process of testing this patch with our encoders but > I wanted to send it now in case it coul

[FFmpeg-devel] [PATCH] avcodec/aarch64/aacencdsp: NEON implementation

This patch supplies handwritten NEON code for AAC. The benchmarks below were collected by invoking these two commands on each of my boards, A78, A72 and Thinkpad x13s: 1) ./tests/checkasm/checkasm --test=aacencdsp --bench --runs=12 2) ./ffmpeg -y -t 10:00 -f lavfi -i sine /tmp/foo.aac (the first l

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> The FEC decoder works on the demuxer/transport layer and is > independent from the content layer. > > The FEC decoder parameters can be set by the user according to their > content settings to determine the delay incurred by buffering and > packet loss for a CBR content. A buffer of N packets do

Re: [FFmpeg-devel] [PATCH] libavutil/avstring: av_match_list: Update API documentation

On 2025-01-22 23:19 +0100, [email protected] wrote: > > On 22 Jan 2025, at 22:59, Alexander Strasser via ffmpeg-devel wrote: > > > Since av_match_list was added in commit 0d92b0d5f445d4f2 , this > > function changed its semantics shortly after, especially with > &

Re: [FFmpeg-devel] [PATCH] avfilter/signalstats: add NULL_IF_CONFIG_SMALL

Hi Abdulrahman! I fixed up and tested your patch locally and your change looks fine :) Will include when it when I push my next batch of changes soon'ish. Depending on how it goes it will take a couple of days from now. For your information I will outline the broken parts inline below: On 2025-

Re: [FFmpeg-devel] [PATCH] avutil/aarch64/float_dsp_neon: Refactor ff_vector_fmul_add_neon

On Sun, Jan 19, 2025 at 10:57:57PM +0200, Martin Storsjö wrote: > On Sun, 19 Jan 2025, Krzysztof Pyrkosz via ffmpeg-devel wrote: > > > Removed a branch, unrolled loop. Speed increase bumped from 3.95 to 5.60. > > On what core is that? Please quote the actual output incl

[FFmpeg-devel] [PATCH v2] libavutil/avstring: av_match_list: Update API documentation

Since av_match_list was added in commit 0d92b0d5f445d4f2 , this function changed its semantics shortly after, especially with commit 3c0b98dced394da3 . Signed-off-by: Alexander Strasser --- Diff to v1: * use @p as suggested by ePirat * clarify that the hint about demuxer names is about FFmpe

Re: [FFmpeg-devel] [PATCH 2/2] avformat/hls: Be more picky on extensions

On Thu, 23 Jan 2025, 00:11 Michael Niedermayer, wrote: > Hi Kieran > > On Wed, Jan 22, 2025 at 10:47:52PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > On Wed, 22 Jan 2025, 20:36 Michael Niedermayer, > > wrote: > > > > > This blocks disallowed extensi

Re: [FFmpeg-devel] [PATCH 3/7] avutil/frame: add a param change side data type

On 2025-01-22 21:18 +0100, Nicolas George wrote: > James Almer (12025-01-22): > > Ok, will implement a new struct. > > Thanks. > > I think this code would work: > > typedef struct AVSideDataParamChange > … > intmax_t end_padding; > } AVSideDataSomethingType; > > static const AVSideDataParam

Re: [FFmpeg-devel] [PATCH v3 1/3] avcodec/nvenc: Enable recovery point SEI for intra refresh mode

On Fri, Jan 24, 2025 at 3:59 AM Zhao Zhili wrote: > > > > > On Jan 24, 2025, at 02:02, Timo Rothenpieler wrote: > > > > On 23.01.2025 15:17, Zhao Zhili wrote: > >> From: Zhao Zhili > >> Otherwise all frames can be dropped after seek without the > >> output_corrupt/showall flags. > >> --- > >> l

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> > > The data arrives on multiple sockets, leading to all sorts > > of opportunities for timing behavior and reordering issues. > > how does this matter? > There are routers that put traffic on a different port down a different ISP so you have to compensate for latency delays between the two link

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Fri, 17 Jan 2025, 21:32 Romain Beauxis, wrote: > Le ven. 17 janv. 2025 à 08:32, Kieran Kunhya > a écrit : > > > > On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya > wrote: > > > > > > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis < > [email protected]> wrote: > > > > > > > > Hi, > > > >

Re: [FFmpeg-devel] [PATCH 2/2] configure: Use -fno-sanitize-recover

19:12, Vitaly Buka via ffmpeg-devel wrote: > > UBSAN by default is just prints a mesage and > > moves on. This hides a few UBs in fate-suite. > > > > Signed-off-by: Vitaly Buka > > --- > > configure | 4 ++-- > > libavcodec/aacen

Re: [FFmpeg-devel] [PATCH v2] fix stride calculation in slice_table for multi-slice field video deblocking

On Tue, Dec 24, 2024 at 9:34 AM Lingyi Kong wrote: > > add fate test case > > Signed-off-by: Lingyi Kong For whatever reason PATCHv4 is in neither of my email boxes, one of which is subscribed to ffmpeg-devel, the other of which is not subscribed but I still receive the emails. It's a great syst

Re: [FFmpeg-devel] Democratization

The mere possibility that the CC could "intervene" about anything has a very > chilling effect. Few people will touch finances in such an environment. > Bascially this will make use of money in the future more difficult. > In the past we just all tried to do the right thing for the project > but if

Re: [FFmpeg-devel] [PATCH 2/2] configure: Use -fno-sanitize-recover

On Fri, Jan 17, 2025 at 3:12 PM James Almer wrote: > On 1/17/2025 7:53 PM, Vitaly Buka via ffmpeg-devel wrote: > > My confusion here is that it looks like ffmpeg developers care about UB, > I > > see from time to time large cleanups, but there are a bunch of unfixed >

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Mon, Jan 20, 2025 at 2:51 PM Nicolas George wrote: > > Kieran Kunhya via ffmpeg-devel (12025-01-17): > > I am the author of the only known functional OSS implementation of FEC. > > Seen from here, your rejection of this proposal looks a teeny tiny > little bit like trying

Re: [FFmpeg-devel] Democratization

> If the CC takes a clear action, this whole drama simply stops. Otherwise > i suspect it will lead to a fork eventually. In the fork case they will leave > with > several others. I think thats a much bigger loss I agree, Anton is gone because of your inflammatory behaviour (banning, censorship e

Re: [FFmpeg-devel] Democratization

On Sun, Jan 26, 2025 at 9:24 PM Michael Niedermayer wrote: > > Hi Kieran > > On Sun, Jan 26, 2025 at 07:39:38PM +, Kieran Kunhya via ffmpeg-devel > wrote: > > > I remember such a IRC session before the libav fork. > > > It is very similar to this here > &g

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename 0x0502 CC format

> > Or is there any reason to not call it what it is (Dish)? There are Sega or > Nintendo audio decoders and other examples and a cryptic description like > "DVB 0502" renders it useless for almost everybody. > Agreed. Kieran > ___ ffmpeg-devel mailing

Re: [FFmpeg-devel] Democratization

On Sun, Jan 26, 2025 at 8:40 PM Rémi Denis-Courmont wrote: > > With my CC hat on, > > Le sunnuntaina 26. tammikuuta 2025, 21.39.38 UTC+2 Kieran Kunhya via ffmpeg- > devel a écrit : > > With Anton leaving the project because of you, Paul forking and James > > lea

Re: [FFmpeg-devel] Democratization

On Sun, Jan 26, 2025 at 8:51 PM Kieran Kunhya wrote: > > On Sun, Jan 26, 2025 at 8:40 PM Rémi Denis-Courmont wrote: > > > > With my CC hat on, > > > > Le sunnuntaina 26. tammikuuta 2025, 21.39.38 UTC+2 Kieran Kunhya via ffmpeg- > > devel a écrit : > > &

Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

> > While this is a very valid concern for some kinds of frame side data, it > does not apply to CC data. It's either in every frame or none. If a > provider generally broadcasts CC, then it's always present in every frame, > even during programs for which no CC is available - it's always there. Li

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename 0x0502 CC format

On Sun, 26 Jan 2025, 00:31 Soft Works, wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Marth64 > > Sent: Sunday, January 26, 2025 1:14 AM > > To: FFmpeg development discussions and patches > [email protected]> > > Subject: Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg1

Re: [FFmpeg-devel] Democratization

> I remember such a IRC session before the libav fork. > It is very similar to this here > 4+ people, who simply accuse me of everything (on IRC though) > this serves no purpose. There is no common ground here Hi Michael, With Anton leaving the project because of you, Paul forking and James leavi

Re: [FFmpeg-devel] [PATCH] avcodec/aarch64/aacencdsp: NEON implementation

On Sun, Jan 26, 2025 at 01:29:38AM +0200, Martin Storsjö wrote: > With the following diff: > > @@ -40,8 +41,8 @@ function ff_aac_quant_bands_neon, export=1 > moviv5.4s, 0x80, lsl #24 > .irp signed,1,0 > \signed: > -subsw3, w3, #4 > ld1

Re: [FFmpeg-devel] [PATCH v2 00/11] fix broken CC detection and ffprobe fields (cover letter)

On Mon, Jan 27, 2025 at 7:03 PM Soft Works wrote: > > > From: ffmpeg-devel On Behalf Of > > Kieran Kunhya via ffmpeg-devel > > Sent: Monday, January 27, 2025 10:40 AM > > > While this is a very valid concern for some kinds of frame side > > data, it > >

[FFmpeg-devel] [PATCH] swscale/aarch64/rgb2rgb: Implemented NEON shuf routines

The key idea is to pass the pre-generated tables to the TBL instruction and churn through the data 16 bytes at a time. The remaining 4 elements are handled with a specialized block located at the end of the routine. The 3210 variant can be implemented using rev32, but surprisingly it is slower tha

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Sun, 19 Jan 2025, 22:22 Michael Niedermayer, wrote: > The part i do not agree with and iam not convinced about is that this > cannot be done in a clean and fully working and heuristics free > way in the real world. > Protocols are not the same as codecs. Just because you have a hammer, everyt

Re: [FFmpeg-devel] [PATCH] avcodec/hevc/hevcdec: Don't add to null pointer

Hello, Would it be possible to merge this patch? Thanks, Vitaly ___ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subje

Re: [FFmpeg-devel] Democratization

On Sat, 25 Jan 2025, 21:49 Rémi Denis-Courmont, wrote: > Le lauantaina 25. tammikuuta 2025, 22.26.44 UTC+2 Michael Niedermayer a > écrit > : > > I had posted one joke on my personal twitter that i deleted a few hours > > later as people seem to have misunderstood it. > > It is completely irreleva

Re: [FFmpeg-devel] [PATCH] libavcodec/mpeg12dec.c: rename 0x0502 CC format

On Sat, 25 Jan 2025, 22:53 Marth64, wrote: > Hello, > > I am to blame here for suggesting DVB_0502 as the name. > I realize it was not the best choice and apologize for wasting your > cycles on this. > > Looping in Keiran as we had discussed this over IRC briefly a few weeks > back. > As I don't

Re: [FFmpeg-devel] Democratization

On Wed, Jan 29, 2025 at 6:27 PM Marth64 wrote: > > Here is an idea, > Can we try to lay out the friction points in a table or bullet format > where we can separate the issue from emotion and direct name calling? > > For example, > " * Community has issue ABC but we can't move forward because senio

Re: [FFmpeg-devel] GSoC 2025

On Wed, Jan 29, 2025 at 7:01 PM Michael Niedermayer wrote: > > Hi Yigithan > > Its good that you bring these issues up. > Discussing about them is a step towards solving them > > see my coments inline below > > On Wed, Jan 29, 2025 at 06:51:40PM +0300, Yigithan Yigit wrote: > > Hi Michael, > > > >

Re: [FFmpeg-devel] Democratization

> > "Nothing to hide" only works if the folks in power share the values of > you and everyone you know entirely and always will -- Tom Scott > I agree fully with Tom Scott's comment and it's a great irony that it's at the end of this email as well as in the context of the last few months where you

[FFmpeg-devel] Backporting makefile targets fate-list-failing and fate-clear-reports

Hi all! I'm thinking about backporting commit 1e76bd2f394a01c1 [1] to all releases listed on our download page. It is a new feature for the build system, but not used to build ffmpeg or otherwise related to the generated binaries. It's of utility when doing backports because it makes it easy to

Re: [FFmpeg-devel] [PATCH v2] avformat/vqf: Propagate errors from add_metadata()

On 2025-01-01 06:15 +0100, Michael Niedermayer wrote: > Suggested-by: Marton Balint > Signed-off-by: Michael Niedermayer > --- > libavformat/vqf.c | 21 ++--- > 1 file changed, 14 insertions(+), 7 deletions(-) > > diff --git a/libavformat/vqf.c b/libavformat/vqf.c > index 79deb33

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/vf_addroi: Add missing NULL termination to addroi_var_names[]()

On 2025-01-05 05:44 +0100, Michael Niedermayer wrote: > Fixes: out of array read > > Found-by: Elias Myllymäki > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_addroi.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavfilter/vf_addroi.c b/libavfilter/vf_addroi.c > index d

Re: [FFmpeg-devel] Worsening messages

It's Christmas day, give it a rest. Kieran On Wed, Dec 25, 2024 at 1:31 PM Michael Niedermayer wrote: > > Hi Community, Community Commitee, Moderators > > The message: lists.ffmpeg.org pipermail ffmpeg-devel/2024-December/337868.html > Is unacceptable. We had alot of messages but this one went t

Re: [FFmpeg-devel] [PATCH] configure: Include quotes around pkg_version

On 2024-12-21 19:29 -0500, J Shiff wrote: > On Sat, Dec 21, 2024 at 5:44 PM Alexander Strasser via ffmpeg-devel > wrote: > > > > On 2024-12-16 16:19 -0500, Joe Schiffler wrote: > > > Since $pkg_version includes spaces, builds can fail in some MSYS > > > envir

Re: [FFmpeg-devel] [PATCH 2/5] lavc/container_fifo: move to lavu and make public

On 2024-12-15 22:20 +0100, Alexander Strasser via ffmpeg-devel wrote: > On 2024-12-11 15:05 +0100, Anton Khirnov wrote: > > This can be useful in other places, e.g. it can replace objpool in > > fftools. > > > > The API is modified in the following nontrivial ways: &

[FFmpeg-devel] [PATCH 2/2] configure: Use -fno-sanitize-recover

UBSAN by default is just prints a mesage and moves on. This hides a few UBs in fate-suite. Signed-off-by: Vitaly Buka --- configure | 4 ++-- libavcodec/aacenc_pred.c | 1 + libavcodec/ffv1dec.c | 1 + libavcodec/ffv1enc_template.c | 1 + libavcodec/get_bits.h

[FFmpeg-devel] [PATCH 1/2] .gitignore: ignore fate-suite

Signed-off-by: Vitaly Buka --- .gitignore | 1 + 1 file changed, 1 insertion(+) diff --git a/.gitignore b/.gitignore index 9cfc78b414..6fcbddad3c 100644 --- a/.gitignore +++ b/.gitignore @@ -43,3 +43,4 @@ /tools/python/__pycache__/ /libavcodec/vulkan/*.c /libavfilter/vulkan/*.c +/fate-suite/

Re: [FFmpeg-devel] [PATCH 2/2] configure: Use -fno-sanitize-recover

I assume "recover" mode is there unintentionally. "-fno-sanitize-recover" helps to keep the code clean. On Thu, Jan 16, 2025 at 11:13 AM Vitaly Buka wrote: > UBSAN by default is just prints a mesage and > moves on. This hides a few UBs in fate-suite. > > Signed-off-by: Vitaly Buka > --- > conf

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis wrote: > > Hi, > > Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya > a écrit : > > > > On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis > > wrote: > > > > > > Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya > > > a écrit : > > > > > > > > On Thu, 16 Jan 2

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Fri, Jan 17, 2025 at 2:24 PM Kieran Kunhya wrote: > > On Fri, Jan 17, 2025 at 2:00 PM Romain Beauxis > wrote: > > > > Hi, > > > > Le jeu. 16 janv. 2025 à 16:40, Kieran Kunhya > > a écrit : > > > > > > On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis > > > wrote: > > > > > > > > Le jeu. 16 ja

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> Don't assume he will not extend the implementation. Ask him instead what > he plans to do in the long term. > And this could also be marked as experimental, in which case if > abandoned or proven unstable for several real world cases, it can be > removed or disabled. "the most simple and elegant

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Fri, Jan 17, 2025 at 2:48 PM James Almer wrote: > > On 1/17/2025 11:42 AM, Nicolas George wrote: > > James Almer (12025-01-17): > >> Don't assume he will not extend the implementation. Ask him instead what he > >> plans to do in the long term. > >> And this could also be marked as experimental,

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> A simple and clean mpeg FEC implementation will do no harm to FFmpeg, > instead it will improve FFmpegs capabilities. For the reasons I have described this is not possible. It's similar to the way the kernel hides all the idiosyncrasies of real world TCP. Kieran

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

> > FEC requires tons of heuristics to work in the real world. > > Besides your word, is there some evidence ? > > (and the question is not that YOUR implementation needs > "tons of heuristics to work in the real world." or the reference > does but that EVERY implementation does) > > You seem to

Re: [FFmpeg-devel] [PATCH] avutil/vulkan_glslang: windows build improvements

On 2025-01-15 7:38 p.m., Koushik Dutta wrote: For my use case I ended up creating a custom pkgconfig file. My platform and compiler is windows and msvc. I was unable to get the existing configure to work correctly with this environment and opted for pkgconfig as the hook for my environment. Is t

[FFmpeg-devel] Pausing the heated discussions

Hi all! I'm unhappy with what ensued here on the FFmpeg development mailing list; especially in the recent months. With the current culminations, and the stress and influx of mails it caused for all subscribers espescially in this for many of us rather busy time of the family year, I would like t

Re: [FFmpeg-devel] FFmpeg governance and accusations

> About a timescale, theres not a single proposal. Short of simply > resigning and handing FFmpeg out to some random dictator who picks it up. > > There is a resposibility here. I cannot and will not simply leave FFmpeg > to whoever likes to pick it up Classic tin pot dictator behaviour, setting a

Re: [FFmpeg-devel] FFmpeg governance and accusations

On Tue, 31 Dec 2024, 13:14 Michael Niedermayer, wrote: > In case most people want democratication and its actually an important > thing > for them. Then sure we will make it happen eventually. > This is a non trivial problem though but i had a surprising "revelation" > yesterday how this could be

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_frei0r: support mixer2 and mixer3 plugins

+if (in[i]->linesize[0] != out->linesize[0]) { +AVFrame *aligned = ff_default_get_video_buffer2(outlink, outlink->w, outlink->h, 1); +ret = av_frame_copy(aligned, in[i]); +copies |= 1 << i; +in[i] = aligned; +goto end; +}

Re: [FFmpeg-devel] FFmpeg governance

On Thu, 2 Jan 2025, 06:49 compn, wrote: > On Thu, 2 Jan 2025 02:23:08 +, Kieran Kunhya via ffmpeg-devel wrote: > > > On Wed, Jan 1, 2025 at 11:10 PM compn wrote: > > > > > > On Tue, 31 Dec 2024 17:28:31 +0000, Kieran Kunhya via ffmpeg-devel > > > wrote

Re: [FFmpeg-devel] Democratization

> In fact the current developers > already WILL TODAY vote the way their employer wants them to By that argument you will vote the way FFlabs wants to and therefore are biased and must resign. Unless you are somehow incorruptible compared to everyone else? Regards, Kieran Kunhya

[FFmpeg-devel] [PATCH] doc/protocols: fix/improve RTP documentation

Signed-off-by: Stefan Pöschel --- doc/protocols.texi | 14 +- 1 file changed, 9 insertions(+), 5 deletions(-) diff --git a/doc/protocols.texi b/doc/protocols.texi index ed70af4b33..969f4bf022 100644 --- a/doc/protocols.texi +++ b/doc/protocols.texi @@ -1150,10 +1150,15 @@ ffplay "rt

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Thu, 16 Jan 2025, 20:48 Kieran Kunhya, wrote: > On Thu, 16 Jan 2025, 20:15 Romain Beauxis, > wrote: > >> This patch implements the decoding logic for the FEC error- >> correction method described in the Pro-MPEG CoP #3-R2 FEC[1] >> >> We are still in the process of testing this patch with our

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Thu, Jan 16, 2025 at 9:35 PM Romain Beauxis wrote: > > Le jeu. 16 janv. 2025 à 14:48, Kieran Kunhya > a écrit : > > > > On Thu, 16 Jan 2025, 20:15 Romain Beauxis, wrote: > >> > >> This patch implements the decoding logic for the FEC error- > >> correction method described in the Pro-MPEG CoP

Re: [FFmpeg-devel] [PATCH v0] Implement promeg decoder.

On Thu, 16 Jan 2025, 20:15 Romain Beauxis, wrote: > This patch implements the decoding logic for the FEC error- > correction method described in the Pro-MPEG CoP #3-R2 FEC[1] > > We are still in the process of testing this patch with our encoders but > I wanted to send it now in case it could use

[FFmpeg-devel] [PATCH] avcodec/hevc/hevcdec: Don't add to null pointer

`POS(1,` and `POS(2,` may trigger UBSAN report: "runtime error: applying non-zero offset 304 to null pointer" Looks like values are not used without `chroma_format_idc`, so maybe there is no other issues than the UB. Can't reproduce with "fate". Signed-off-by: Vitaly Buka --- libavcodec/hevc/h

Re: [FFmpeg-devel] [PATCH 1/2] .gitignore: ignore fate-suite

Sorry, I messed up my subscription, so will reply slightly off-thread. Timo Rothenpieler via ffmpeg-devel wrote: > I don't think the fate-suite should be sitting in the source tree. > Also, there is no guarantee every user/developer will name it that exact > name? Or is that

Re: [FFmpeg-devel] [PATCH] doc/protocols: fix/improve RTP documentation

Sorry, I tried git send-email the first time and didn't check the wrapping before sending. Please find the patch attached as file. Am 16.01.25 um 20:47 schrieb Michael Niedermayer: On Wed, Jan 15, 2025 at 05:27:39PM +0100, Stefan Pöschel via ffmpeg-devel wrote: Signed-off-by: Stefan Pö

Re: [FFmpeg-devel] Fw: GSoC 2025: Please review your Project Ideas lists

On Fri, Feb 14, 2025 at 7:28 PM Michael Niedermayer wrote: > > Hi everyone > > Please help improve the gsoc 2025 page > > 2 ideas are missing backup mentors, if you are able please > add yourself to them as backup mentor > > Also please add more ideas! > And help review the page and ideas to ensur

Re: [FFmpeg-devel] Fw: GSoC 2025: Please review your Project Ideas lists

On Fri, 14 Feb 2025, 21:29 Steven Liu, wrote: > > > Kieran Kunhya via ffmpeg-devel 于2025年2月15日 > 周六04:21写道： > >> On Fri, Feb 14, 2025 at 7:28 PM Michael Niedermayer >> wrote: >> > >> > Hi everyone >> > >> > Please help improve the

Re: [FFmpeg-devel] [PATCH] avcodec/aarch64/opusdsp_neon: Simplify opus_postfilter_neon

On Sat, Feb 08, 2025 at 01:59:32AM +0100, Lynne wrote: > On 07/02/2025 20:42, Krzysztof Pyrkosz via ffmpeg-devel wrote: > > This change removes one extra floating point operation and simplifies > > load operations at the beginning of the loop by using dedicated register > &

[FFmpeg-devel] [PATCH] checkasm/v210enc.c: Use checkasm_check_type

$subj 0001-checkasm-v210enc.c-Use-checkasm_check_type.patch Description: Binary data ___ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@

[FFmpeg-devel] [PATCH] avformat/mpegenc: increase the default size of the VBV buffer

Increase the default buffer size to match more modern encoding scenarios. --- libavformat/mpegenc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/libavformat/mpegenc.c b/libavformat/mpegenc.c index 6b6763c30f..2b3b98b894 100644 --- a/libavformat/mpegenc.c +++ b/libavform

Re: [FFmpeg-devel] GSoC 2025

On Wed, 12 Feb 2025, 00:20 Michael Niedermayer, wrote: > Hi everyone > > On Wed, Feb 12, 2025 at 06:30:11AM +0800, Steven Liu wrote: > > Michael Niedermayer 于2025年1月28日 周二10:21写道： > > > > > Hi > > > > > > Everyone interested in mentoring a project in 2025, please add your > > > idea(s) to [1]. >

Re: [FFmpeg-devel] [RFC] GSoC 2025 SDR Cleanup

On Wed, 12 Feb 2025, 01:21 Michael Niedermayer, wrote: > Hi all > > Ive added SDR to our GSoC 2025 page as there was just a single project > on that page and the page needs to be more complete yesterday > > If people are against this say this NOW do not wait until we have accepted > a student and

Re: [FFmpeg-devel] [RFC] GSoC 2025 SDR Cleanup

On Wed, 12 Feb 2025, 02:11 Michael Niedermayer, wrote: > On Wed, Feb 12, 2025 at 01:23:09AM +, Kieran Kunhya via ffmpeg-devel > wrote: > > Is this a joke? > > no > > It follows up on Jean Baptistes request here: > https://lists.ffmpeg.org/pipermail/ffmpeg-de

[FFmpeg-devel] [PATCH] swscale/aarch64/rgb2rgb_neon: Implemented uyvytoyuv422

I forgot to include the benchmarks in the previous message, here they are: A78: uyvytoyuv420_neon:6112.5 ( 6.96x) uyvytoyuv422_neon:6696.0 ( 6.32x) yuyvtoyuv420_neon:6113.0 ( 6.95x) yuyvtoyu

[FFmpeg-devel] [PATCH] swscale/aarch64/rgb24toyv12: skip early right shift by 2

It's a minor improvement that shaves off 5-8% from the execution time. Instead of shifting by 2 right away and by 7 soon after, shift by 9 one time. Times before and after: A78: rgb24toyv12_16_200_neon: 5366.8 ( 3.62x) rgb24toyv12_128_60_neon:

Re: [FFmpeg-devel] GSoC 2025

Adding @Cc This is a blatant attempt to push an unrelated pet project into FFmpeg under the Gsoc banner with no notice. It's also unfair to students applying as there was serious community pushback against this last time. Kieran On Wed, 12 Feb 2025, 01:16 Kieran Kunhya, wrote: > > > On Wed, 1

[FFmpeg-devel] [PATCH] avformat/hlsenc: calculate bitrate for segments with duration < 0.5

The previous code sets the bitrate to be calculated only when duration>0.5, which is obviously not general enough. In some scenarios, we may need to set hls_time<0.5, then the generated segments are all <0.5. At this time, because the bitrate is not calculated, max_bitrate is empty, and ff_hls_

Re: [FFmpeg-devel] [PATCH v5] Mark C globals with small code model

Patch version v5: - Uses two new macros DECLARE_ASM_VAR (used for both external and inline asm) and DECLARE_EXTERNAL_ASM_VAR (used only for external asm) - I intend to remove explicit existing use of attribute_visibility_hidden in follow-up patch and instead use DECLARE_EXTERNAL_ASM_VAR for those v

Re: [FFmpeg-devel] Access to the ARM server

On Tue, 25 Mar 2025, 08:47 Zhao Zhili, wrote: > Hi, > > From Twitter > > Unlike the majority of hardware/cloud companies, Ampere have supported > the FFmpeg project by giving us a 160-core ARM server for development. > > Is the Ampere ARM server still available? Is it only for FATE or other > par

Re: [FFmpeg-devel] [PATCH] speexdec: fix framesize for ultra-wideband

On Thursday, March 13th, 2025 at 2:54 PM, Tristan Matthews wrote: > This matches how the libspeex decoder is calculating frame size (except in > clamp form). > > Fixes #11495 > --- > libavcodec/speexdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/speex

Re: [FFmpeg-devel] Access to the ARM server

would like to report it. Kieran On Tue, Mar 25, 2025 at 8:55 AM Nicolas George wrote: > > Kieran Kunhya via ffmpeg-devel (HE12025-03-25): > > The server belongs to @Jean-Baptiste Kempf > > Are you saying that the tweet that says “giving ***us*** a 160-core ARM > server” (em

Re: [FFmpeg-devel] [PATCH] swscale/x86/rgb2rgb: optimize AVX2 version of uyvytoyuv422

On Mon, 3 Mar 2025, 16:38 Shreesh Adiga, <[email protected]> wrote: > On Thu, Feb 20, 2025 at 6:51 PM Shreesh Adiga > <[email protected]> wrote: > > > > Currently the AVX2 version of uyvytoyuv422 in the SIMD loop does the > following: > > 4 vinsertq to have interleaving of the

[FFmpeg-devel] [PATCH v5] Mark C globals with small code model

By default, all globals in C/C++ compiled by clang are allocated in non-large data sections. See [1] for background on code models. For PIC (Position independent code), this is fine as long as binary is small but as binary size increases, users maybe want to use medium/large code models (-mcmodel=m

[FFmpeg-devel] [PATCH] avformat/dashdec: just make seg->url in absolute path once

Should fix ticket 11543 if input url is relative path, the seg-url would make absolute url twice in get_content_url and open_input function but it doesn't need make absolute url in open_input since we set it already Signed-off-by: Jack Lau --- libavformat/dashdec.c | 2 +- 1 file changed, 1 i

[FFmpeg-devel] [PATCH] dashenc: allow setting custom start time for Live DASH streams - Follow-Up

Hi all, I submitted this patch [1] back in August to add an option for setting a custom start time in dashenc for Live DASH streams, rather than defaulting to system time. It’s a small change that passes all tests and preserves existing behavior unless the option is used. I’d really appreciate

Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: Use CBR filler data consistently across codecs

On Sun, Mar 30, 2025 at 12:04 AM Cameron Gutman wrote: > > Previously, AV1 used filler data with CBR by default while H.264 > and HEVC did not. Make this consistent by using filler data in > CBR mode across all codecs. > > Since there are valid reasons to use CBR with or without filler, > also add

[FFmpeg-devel] [PATCH] avformat/rtpdec_mpeg4: add need_parsing for rtsp AAC

fix ticket #11531 the rtsp aac did not marked keyframe which cannot easy copy to output. because f265f9c9d04863180503707bfad285f48e6bf080 commit change the AAC props to match xHE-AAC. in some formats like MOV, need_parsing is set, so AAC can be still parsed be keyframe but rtsp did not, so this

Re: [FFmpeg-devel] APV codec with OpenAPV support

On Tue, 22 Apr 2025, 09:44 , wrote: > Hi, > > > > I'm Dariusz from Samsung Electronics, you can know me from last VDD in > Korea, I was presenting APV. > > > > I'm glad that Mark created native APV decoder. As you might know we're also > working on APV implementation for FFmpeg. > > Our approach

Re: [FFmpeg-devel] [PATCH] postproc/postprocess_template: Fix reading uninitialized pixels in dering_C()

On Tue, 22 Apr 2025, 00:44 Michael Niedermayer, wrote: > Sponsored-by: Sovereign Tech Fund > Signed-off-by: Michael Niedermayer > I thought we decided postproc work in STF wasn't going to happen? Note that the STF wiki doesn't mention anything about bugfixes to libpostproc. Kieran >

Re: [FFmpeg-devel] [PATCH] avfilter/vf_lut3d_opencl Initial support for OpenCL implementation of vf_lut3d.

Studeny On Apr 28, 2025 at 13:39 +0300, Jan Studený via ffmpeg-devel , wrote: > --- > libavfilter/Makefile | 1 + > libavfilter/allfilters.c | 1 + > libavfilter/opencl/lut3d.cl | 177 ++ > libavfilter/opencl_source.h | 2 + > libavfilter/vf_lu

Re: [FFmpeg-devel] [PATCH v5] Mark C globals with small code model

Ping. On Tue, Apr 15, 2025 at 4:22 PM Pranav Kant wrote: > Hello again. Is there anything else I can do here? > > On Fri, Apr 4, 2025 at 11:40 AM Pranav Kant wrote: > >> Any thoughts on this? >> >> On Thu, Mar 20, 2025 at 5:30 PM Pranav Kant wrote: >> >>> Patch version v5: >>> - Uses two new m

[FFmpeg-devel] [PATCH] libavformat/mov: FMp4 Fixes duration calculation for individual streams on videos where crash occurs.

Both the audio and video sidx boxes at the end point to a range corresponding to the final mdat atom. Since there is no mfra following the final mdat when recording crashes, current logic sets the flag frag_index.complete flag on the penultimate sidx atom since it points to the end of the file.

Re: [FFmpeg-devel] [RFC] STF 2025

On Fri, 15 Nov 2024, 18:12 Thilo Borgmann via ffmpeg-devel, < [email protected]> wrote: > Hi, > > Am 17.05.24 um 15:49 schrieb Michael Niedermayer: > > Hi all > > > > Before this is forgotten again, better start some dicsussion too early > than too late &

[FFmpeg-devel] [PATCH v2] avfilter/vf_lut3d_opencl Initial support for OpenCL implementation of vf_lut3d.

The comile error is fixed by adding opencl dependency to configure. --- configure | 1 + libavfilter/Makefile | 1 + libavfilter/allfilters.c | 1 + libavfilter/opencl/lut3d.cl | 177 + libavfilter/opencl_source.h | 2 + libavfilter/vf_lut

[FFmpeg-devel] Patch for Phantom .cine files

Hello, I'm offering a patch to add support for additional CFA types when reading phantom cine files. This was necessary to get ffmpeg to debayer the cine files produced by my newer Phantom C321. Max Rudolph Associate Professor | Earth and Planetary Sciences | UC Davis website

Re: [FFmpeg-devel] [PATCH 2/2] avformat/id3v2: Check that decode_str() did advance

> On Apr 15, 2025, at 08:59, softworkz . > wrote: > > > >> -Original Message- >> From: ffmpeg-devel > > On Behalf Of >> Michael Niedermayer >> Sent: Dienstag, 15. April 2025 01:20 >> To: FFmpeg development discussions and patches > de...@ffmpe

<    16   17   18   19   20   21   22   23   24   25   >