00:13 <Lynne> most people and players init lavc with as many threads as there are CPUs

00:15 <Lynne> could you also call ff_ffv1_init_slice_contexts() just before decode_slices() is called?

00:16 <Lynne> since the vulkan decoder doesn't use the C decoder's slice state

06:20 <fflogger> [editedticket] helfix: Ticket #11531 ([ffmpeg] [Regression] AAC audio in RTSP no more muxed with "-c copy") updated https://trac.ffmpeg.org/ticket/11531#comment:6

07:37 <cone-810> ffmpeg Andreas Rheinhardt master:2204efc2a656: avcodec/dct: Make declarations and definitions match

07:37 <cone-810> ffmpeg Andreas Rheinhardt master:ffa56f73a9bc: avcodec/ac3dec: Read spx flags at once, not one bit at a time

07:37 <cone-810> ffmpeg Andreas Rheinhardt master:0ce8868878c9: avcodec/hevc/hevcdec: Use bitfield instead of array of flags

07:37 <cone-810> ffmpeg Andreas Rheinhardt master:ca48e7bb707a: avcodec/sbcdsp_data: Make data static

09:35 <fflogger> [editedticket] MasterQuestionable: Ticket #11531 ([ffmpeg] [Regression] AAC audio in RTSP no more muxed with "-c copy") updated https://trac.ffmpeg.org/ticket/11531#comment:7

09:53 <fflogger> [editedticket] MasterQuestionable: Ticket #11500 ([swscale] "swscale" "auto_scale" "yuv420p10le" "Function not implemented"?) updated https://trac.ffmpeg.org/ticket/11500#comment:11

11:00 <fflogger> [newticket] mvignali: Ticket #11536 ([undetermined] prores_aw : Encode Prores 4444 with alpha fail in high resolution) created https://trac.ffmpeg.org/ticket/11536

16:06 <kierank> michaelni: did you remove me from twitter?

16:09 <michaelni> no

16:09 <kierank> https://usercontent.irccloud-cdn.com/file/U22xlEoK/image.png

16:09 <kierank> Who else has access to control this?

16:12 <fflogger> [newticket] birdie: Ticket #11537 ([undetermined] ffmpeg 6.1.3 please?) created https://trac.ffmpeg.org/ticket/11537

16:15 <michaelni> kierank, my account delegation is gone too. Maybe you april fools joke with doge was the wrong joke on the wrong platform

16:16 <kierank> oh, who is in control

16:16 <michaelni> or maybe its just a bug

16:16 <kierank> michaelni: lol

16:17 <kierank> lol, there's a twitter support chat

16:17 <kierank> 🤖 I'm escalating this to a human agent. Your case number is PSDM-XXXXX. We will get back to you within a few days.

16:34 <kasper93> It would be incredibly funny if it weren't a bug

16:44 <toots5446> michaelni, Lynne, ePirat: Is it possible to get an update re: the ogg stream patch set? As I said, I have more work bringing ffmpeg's support for ogg stream inline with what it should be including fixing PTS/DTS discrepancy on secondary streams and removing header packets. If there's no interest in merging the patch I'd appreciate to know as well so I can move on and find other solution to

16:44 <toots5446> make ffmpeg work for our users relying on it for ogg streams. I appreciate all the reviews, I learned a lot and I think that the patchset is looking good now.

16:45 <ePirat> it looks fine to me however its not an area I maintain so I would leave it to michaelni or Lynne to merge it

16:46 <ePirat> (and I dont think I have access to upload the fate samples)

16:47 <Lynne> toots5446: I've been waiting for michaelni to approve

16:47 <Lynne> I've said I'm happy with it so if its fine I'll push it

16:58 <kasper93> If anyone have a second to pull this change, I'd appreciate. https://patchwork.ffmpeg.org/project/ffmpeg/patch/20250401233630.990-1-kasper93@gmail.com/

17:33 <toots5446> Fingers crossed then!

17:33 <toots5446> michaelni: let me know if I can help in any way.

17:44 <michaelni> toots5446, patchset doesnt apply, see ML for exact message but i guess you need to rebase and resend it

18:03 <mkver> michaelni: Can you backup the m_noint.avi file from ticket 1915 to the sample server?

18:20 <toots5446> michaelni: arf yeah some of the recent deprecated API drop happen right next to one of the diff. About to push the new patchset.

18:24 <michaelni> mkver, please mail samples-request at ffmpeg.org

18:26 <mkver> You seem to misunderstand. This is not about a request to upload a sample to fate. This is a request for you to upload the sample m_noint.avi from ticket 1915 (which you have, but which is not on https://streams.videolan.org/ffmpeg/) to upload it there.

18:28 <mkver> Preferably via https://streams.videolan.org/upload/ with the correct ticket number so that anyone can find it.

18:34 <michaelni> mkver, that file is on the ffmpeg sample server since 2 years: https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1915/

18:36 <michaelni> and other tickets have their files in similar looking places, if anyone is looking for one.

18:38 <mkver> Thanks for the info. I only searched in https://streams.videolan.org/ffmpeg/incoming/ (because that's where they will be put when using the sample uploader).

18:50 <ePirat> TIL that is public

20:37 <cone-723> ffmpeg James Almer master:cd1ec359c476: avfilter/vsrc_testsrc: also fill alpha planes with a test pattern in {rgb,yuv}testsrc

20:37 <cone-723> ffmpeg James Almer master:67c489131187: tests/filter-video: add yuvtestsrc tests for yuva444p

20:37 <cone-723> ffmpeg James Almer master:d1f2f8eee002: tests/filter-video: add rgbtestsrc tests for gbrap

21:27 <jamrial> ePirat: your latest patchset went directly to my spam folder for some reason

21:27 <jamrial> also other patches by other people

21:27 <ePirat> yeah happens sometimes for me too

22:13 <ramiro> haasn: 15% to 20% faster by using horizontal loop in asm. I needed to add x_end to SwsOpExec.

22:37 <cone-723> ffmpeg Jun Zhao master:976c16109bb0: doc/ffmpeg: document videotoolbox in -hwaccel option

22:37 <cone-723> ffmpeg Jun Zhao master:efa0c6252faa: fftools/cmdutils: fix error message for "ffmpeg -init_hw_device list"

22:48 <haasn> ramiro: what chunk size were you using for the C loop?

23:08 <ramiro> haasn: I set block_w to 16 if only u8/u16 are used. if u32/f32 are used, then block_w is 8.

23:32 <haasn> oh yes, that's quite low

23:33 <haasn> in the x86 backend I go up to block size 64 for 8-bit processing

23:33 <haasn> at that point the loop overhead is a lot less significant

23:33 <haasn> I was thinking of writing the horizontal loop code in asm

23:33 <haasn> but I'm not sure how to optimize it further, really - the problem is that a lot of data pointers need to be updated

23:33 <haasn> In theory we could use a specialized implementation that updates only actually-needed data pointers

23:33 <haasn> but even so, updating the exec ctx itself will always take time

23:34 <haasn> but I benchmarked this against having the load/store function itself calculate the right offset and came to the conclusion that it was better to bump the pointer in the wrapper than deal with pointer arithmetic during load/store

23:35 <haasn> well, in theory theory theory we could pin the address to dedicated registers like we do for vector registers but.. meh

23:35 <haasn> ramiro: one possible compromise could be to pick a basic block size like 64x1 and have your first dispatch layer be an asm function that directly calls the underlying kernel