02:13 <cone-422> ffmpeg Brad Smith release/7.1:05ff3eb9f2b9: ppc: Recognize the PPC VSX and Power8 CPU flags

08:30 <cone-651> ffmpeg Marvin Scholz master:7554346cb5cf: avdevice/decklink_dec: fix leak on error

08:30 <cone-651> ffmpeg Marvin Scholz master:8e76c993013d: avdevice/decklink_dec: fix leaks on error

08:35 <cone-651> ffmpeg Marvin Scholz release/7.1:963145483cd0: avdevice/decklink_dec: fix leak on error

08:35 <cone-651> ffmpeg Marvin Scholz release/7.1:ebd0ca9fee85: avdevice/decklink_dec: fix leaks on error

10:21 <Lynne> ePirat: the vulkan patches I sent should reduce memory usage further

11:06 <asivery> Hello, everyone. I have a question regarding sending in patches. I've tried sending two patches over the course of the past few months. (2024-July/330634.html, 2024-September/333948.html). The first one got some responses, which were immediately addressed by me, then I got ghosted. The second one got nothing. I'm just asking if I'm doing something wrong. I understand my patches apply to formats 99.9% of ffmpeg users don't use, but I don't think

11:06 <asivery> that's a reason for me to not get any resposes. If anyone could help me, it would be massively appreciated.

11:06 <asivery> Thank you in advance

11:11 <ramiro> asivery: we're short on people to review patches in a timely manner. sometimes (quite often nowadays) patches just get forgotten on the mailinglist. feel free to ping the patches.

11:12 <ramiro> asivery: also don't top-post (as in writing your replies on top of the message), we prefer inline replying since it makes things easier to track and understand.

11:13 <asivery> I see - thank you for the explanation. I'll ping the patch from July, and give that one from September a few more days. I understand that this is an open source project, so people are going to be working on it in their free time, I was just worried I had done something wrong.

11:18 <ramiro> asivery: did you ever run "make fate"? this is how our tests are run. I suggest you add a testcase with the samples you sent. if we can easily test a patch it makes it that much easier to review.

11:19 <asivery> I did run fate. I also sent the fate testcase patch for the July patch as a second email. That got ignored as well.

11:20 <asivery> I didn't write a fate testcase for the September patch.

11:22 <asivery> Also, is the way I send patches over correct? The email provider I use doesn't let me integrate it with git send-mail, so I just send the file format-patch returns as an attachment.

11:23 <ramiro> asivery: merge patches 1 and 2 (add functionality and test), also CC samples-request@ffmpeg.org so that someone can upload the samples before the patch is pushed.

11:23 <cone-651> ffmpeg Martin Storsjö release/7.1:09e9d61d0a12: checkasm/sw_rgb: Revert test additions from e18b46d95fadcbaaf450bda9f1871849f2b0c586

11:25 <ramiro> asivery: we prefer git send-email, but if you can't do that, sending a patch made with format-patch is ok.

11:25 <asivery> Thank you - I'll do that. Do I need to rebase onto the current master?

11:25 <ramiro> asivery: yes, that's always a good idea.

11:26 <asivery> Got it - thanks so much for the help!

12:55 <cone-651> ffmpeg Zhao Zhili master:a2d966324190: avformat/internal: Add ff_get_frame_filename

12:55 <cone-651> ffmpeg Zhao Zhili master:f56a54387b9c: avformat/img2enc: Fix integer truncation when frame_pts is enabled

15:39 <cone-651> ffmpeg Marth64 master:9d3cdf8fa602: MAINTAINERS: update myself for dvdvideo, rcwtdec, rcwtenc

15:54 <haasn> did we have a built-in helper somewhere for exponentially growing arrays? av_dynarray?

15:55 <haasn> seems like it

16:48 <cone-651> ffmpeg Michael Niedermayer release/7.1:0bad953cc549: avcodec/ffv1enc: Fix >8bit context size

16:48 <cone-651> ffmpeg Michael Niedermayer release/7.1:69cf68f5a099: Update for 7.1

16:48 <cone-651> ffmpeg Michael Niedermayer release/7.1:b08d7969c550: RELEASE_NOTES: Based on the version from 5.1

16:54 <Marth64> Lynne: finally up and running; executing test circuit now

16:56 <Marth64> Device does not support the VK_KHR_video_decode_queue extension! apparently

16:59 <Marth64> source is avc

17:09 <Marth64> building from scratch

19:28 <Lynne> you're probably trying to use hardware decoding

19:28 <Lynne> I just want to know about the filters

19:29 <Lynne> as cursed as vulkan is, its not SoC-level cursed

19:41 <Marth64> ah, so i can software decode and hwupload to use filter then

19:42 <Marth64> didn't realize that

20:01 <vipyne> context is looking for a low-lift irc client- does https://kiwiirc.com/ work for anyone? (it's mentioned in the docs here: https://ffmpeg.org/contact.html#IRCChannels)

20:02 <Marth64> libera has their own https://web.libera.chat/

20:02 <Marth64> disclaimer-haven't tested it

20:05 <vipyne> thank you! I'll test it and submit patch to update docs

20:07 <Marth64> already on it

20:07 <Marth64> np

20:08 <Marth64> the original broken URL had query params to set the channel so i am testing if those can carry over

20:13 <vipyne> for future reference, where is the source code for those docs? I'm probably missing something but I don't see them in the repo

20:14 <Marth64> https://git.ffmpeg.org/ffmpeg-web

20:14 <Marth64-web2> abc123

20:40 <vipyne> just curious, is the contribution procedure for ffmpeg-web the same as for ffmpeg? patches still sent to mailto:ffmpeg-devel@ffmpeg.org ?

20:40 <Marth64> Lynne: flip_vulkan looks good. have to go but will run other filters and post a report here

20:40 <Lynne> amazing

20:40 <j-b> vipyne: yes

20:41 <Marth64> i'm testing against https://samples.ffmpeg.org/V-codecs/AVC1/NeroRecode_STD_AVC_(ateme1022).mp4

20:44 <Lynne> I didn't think the rpi4 had enough support to run our code even with the recent changes, I'm glad it does

20:44 <Marth64> it was a pain to build on bullseye so i moved to trixie

20:44 <Lynne> well, at least users there can have a high quality gpu deinterlacer

20:45 <Marth64> yes i will test that

20:45 <Lynne> even if they don't get hardware decoding

20:45 <Marth64> i have some interlaced h264

20:46 <Marth64> actually its a live broadcast so that will be fun

20:46 <Marth64> will write back later - have a good day!

21:06 <Guest33> testguest33

21:12 <Marth64> i did notice #ffmpeg requires nick registration while #ffmpeg-devel does not

21:12 <Marth64> this could confuse people new to irc clicking the link

21:12 <vipyne> +1 to nick registration confusing people

21:17 <Marth64> on unrealircd this is mode +M i believe

21:18 <Marth64> not sure here

21:19 <Marth64> probably best to document this instead i imagine it was put on to block spam

21:26 <haasn> am I seeing it correctly that zimg does all processing internally on floating point values?

21:29 <haasn> for example the dither impl: float x = static_cast<float>(src_p[j]) * scale + offset;

21:32 <haasn> seems like it's just the dither code

21:32 <haasn> other processing has integer modes

21:32 <haasn> weird