01:07 <cone-368> ffmpeg softworkz master:97d680d45017: fftools/textformat: Extract and generalize textformat api from ffprobe.c

01:07 <cone-368> ffmpeg softworkz master:d7a3f68feae0: fftools/ffprobe: Change to use textformat api

01:07 <cone-368> ffmpeg softworkz master:93ae305ce16e: fftools/ffprobe: Rename AVTextFormatContext variables (w => tfc)

01:07 <cone-368> ffmpeg softworkz master:15e99b239845: fftools/ffprobe: Rename writer_print_section_* and WriterContext

02:20 <Lynne> JEEB: streaks bad audio codec saga continues

02:21 <Lynne> they've switched from AAC-LTP to... Vorbis!

02:22 <Lynne> and there's no doubt they're using our encoder

02:23 <Lynne> seriously... is this a joke? are they trying to get us to improve our audio encoders by picking the worst ones we have?

02:36 <Lynne> *correction, it's aac-lc

02:37 <Lynne> and its without any shadow of a doubt made by our encoder, an ancient version, at 61kbps

04:13 <fflogger> [editedticket] malaawar: Ticket #11542 ([ffmpeg] gdigrab sometimes fails to capture specific windows on some machines) updated https://trac.ffmpeg.org/ticket/11542#comment:10

04:24 <fflogger> [editedticket] malaawar: Ticket #11542 ([ffmpeg] gdigrab sometimes fails to capture specific windows on some machines) updated https://trac.ffmpeg.org/ticket/11542#comment:11

04:24 <fflogger> [editedticket] malaawar: Ticket #11542 ([ffmpeg] gdigrab sometimes fails to capture specific windows on some machines) updated https://trac.ffmpeg.org/ticket/11542#comment:12

07:13 <fflogger> [editedticket] fildens: Ticket #11430 ([avformat] [Regression] Data stream in output may glitch "-stats" display since 7.0) updated https://trac.ffmpeg.org/ticket/11430#comment:13

09:27 <cone-175> ffmpeg Zhao Zhili master:f702cf422a23: avcodec/mediacodecdec: Reset optional fields when parse format

10:22 <cone-175> ffmpeg Dmitrii Ovchinnikov master:b02985b12c30: avcodec/amfenc_av1: Add B-frame QP control

12:09 <mkver> jamrial: Why is it necessary to add LCEVC side data before get_buffer calls (as you did in d250cc02e2502692d3d9ae58780a9caec236ad09)?

12:10 <jamrial> mkver: because of https://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/decode.c;h=14702fb04132d6990e21a5d4bd17c7e5a077e03e;hb=HEAD#l1577

12:11 <jamrial> h264 should do the same, but currently isn't, and so lcevc is not working for it

12:12 <mkver> But if there is LCEVC packet side data and in-band side data, which one will win with the current code? Isn't it the packet side data?

12:13 <jamrial> there's an option to choose who wins

12:18 <mkver> Wait, currently in-band LCEVC will unconditionally override side-data LCEVC: It is added to the frame at a time when there is no side data yet (because it is blank) and lateron ff_decode_frame_props_from_pkt() (or rather side_data_map()) does not add side data if it is already there, regardless of the preference flag.

12:19 <mkver> (This is based on reading the code, not on actual samples.)

12:31 <jamrial> mkver: mmh, true

12:31 <jamrial> it shouldn't matter in a real world scenario, though

12:31 <jamrial> but i guess it should be fixed