00:31 <BBB> wbs: yes, I suppose that would be good. michaelni: are you in charge of backports?

00:38 <Traneptora> it's 1 a.m. in Europe rn so he may be asleep

00:41 <BtbN> nobody is directly in charge of backport

00:41 <BtbN> he just picks a ton of fixes every release on an old branch

00:42 <BtbN> If a patch is fix for a bug that does not introduce new features or breaks anything, just push it

00:48 <Traneptora> I was under the impression the usual method is that if you fix bugs without changing (non-bug) behavior then you just backport it as far as it merges

00:48 <Traneptora> i.e. as far as it applies cleanly

00:50 <BtbN> yeah, just cherry-pick away for pure bugfixes

00:53 <BBB> don't have a lot of experience with backports, afaik I've never backported anything

01:03 <cone-141> ffmpeg Leo Izen master:f3c408264554: avcodec/libjxl: add animated JPEG XL encoder

01:03 <cone-141> ffmpeg Leo Izen master:07e54f9b5c1c: avformat/jpegxl_anim_dec: use new animated JPEG XL codec ID

01:35 <michaelni> BBB, i try to backport my bugfixes but i have never tried to backport everyones bugfixes. So unless we find someone that does that, everyone has to backport their bugfixes which they want backported

01:35 <michaelni> Traneptora, sleep? what is that ?

04:41 <fflogger> [editedticket] Gyan: Ticket #9814 ([avformat] time_scale / num_units_in_tick is not infinite precision) updated https://trac.ffmpeg.org/ticket/9814#comment:28

05:02 <fflogger> [editedticket] Balling: Ticket #9814 ([avformat] time_scale / num_units_in_tick is not infinite precision) updated https://trac.ffmpeg.org/ticket/9814#comment:29

09:04 <dmacks> Are there searchable archives of the ffmpeg-devel mailing list?

09:48 <pross> dmacks: no, other than google/yandex/etc.

10:29 <dmacks> thanks

12:12 <beastd> any opinion on, one of hardest things in computer science, the naming of this new public API? https://ffmpeg.org/pipermail/ffmpeg-devel/2024-December/337924.html

12:20 <BBB> michaelni: what are the currently maintained release branches?

12:21 <BBB> and what is the process? is cherry-pick 060464105b -3 enough? or does it need more information?

12:24 <beastd> IMHO try the cherry pick (see if it runs through without problems, git will stop and explain if things don't fit). Check if all expected commits are on top of the branch now. then build and run fate. if you think all is ok try to push the branch. continue with the next release branch.

12:25 <BBB> I can't run fate, the changes are on arm

12:25 <BBB> I don't have arm

12:25 <beastd> it's been a while since i backported stuff for ffmpeg, but IIRC that's how i did it

12:25 <michaelni> BBB, maintained release branches are the ones on https://ffmpeg.org/download.html, though when backporting has been done to release n and m then anything between is probably "free" and no work

12:26 <michaelni> also please add -x to the cherry pick so the commit hash of the source commit is in the commit message (this makes tracking things easer)

12:26 <BBB> git cherry-pick -x $hash -3

12:26 <michaelni> yes

12:26 <BBB> ok

12:26 <beastd> yeah, -x is good for this picks. it's not default because it often makes no sense. but especially when backporting it's good because you are picking from a stable branch

12:26 <BBB> 2.8, 3.4, 4.2, 4.3, 4.4, 5.1, 6.1, 7.0, 7.1

12:27 <beastd> BBB: ok i can give it a run on aarch64 after it's pushed. think i could also run on arm but that will be a little more involved.

12:28 <BBB> oh wow it applies to 3.4 cleanly

12:29 <BBB> (2.8 did not)

12:29 <michaelni> if you do a lot of testing then seting up qemu+cross build is not hard, ubuntu at least has all packages one needs for several architectures like arm and mips

12:29 <kurosu> Sounds like that should be automated, but I imagine fate+samples are only valid for master and not versioned, so no easy to fully validate a branch ?

12:30 <kurosu> *not easy

12:30 <kurosu> (branch or tag)

12:30 <beastd> kurosu: iirc samples shold not be changed in fate collection. so it should work also for older fate.

12:30 <michaelni> fate works with old checkouts

12:31 <kurosu> ah right, it's the output that needs updating, and that's under the regular git

12:31 <beastd> only add new samples, never change or remove old ones (at some point we could consider deleting old samples, but as long as it's not needed i would not)

12:32 <BBB> man, sometimes shell scripting feels like cheating

12:33 <cone-369> ffmpeg Janne Grunau release/3.4:180f8216cdb6: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:33 <cone-369> ffmpeg Janne Grunau release/3.4:80ef3328b559: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:33 <cone-369> ffmpeg Janne Grunau release/3.4:970ca1e0f259: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/4.2:bfed437be84e: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/4.2:a342536d6b1b: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/4.2:655b6f887788: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <kurosu> So it would be nice that whatever populates fate.ffmpeg.org can also be run on tags. But maybe it can already, or it's worthy of some sponsorship to make the needed changes

12:34 <cone-369> ffmpeg Janne Grunau release/4.3:69107495c5e4: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/4.3:131bd9436c2a: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/4.3:6cd0bdf3b064: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/4.4:d3b9fd51b82d: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/4.4:fe955a7d779f: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <BBB> beastd: ok pushed, please test if you can on one-or-some of these branches

12:34 <cone-369> ffmpeg Janne Grunau release/4.4:7b0213a111db: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/5.1:0dac8251f741: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/5.1:3562311c3027: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/5.1:14afc43c27d9: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/6.1:7f0d4aa61c55: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/6.1:6a2b9d4c29be: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/6.1:2a29fe87c42a: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/7.0:7f1e2090285e: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/7.0:0407cd499058: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/7.0:bb1a9c5932d3: vp9: recon: Use emulated edge to prevent buffer overflows

12:34 <cone-369> ffmpeg Janne Grunau release/7.1:1a254c5354fb: aarch64: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/7.1:535a8262ccf6: arm: vp9mc: Load only 12 pixels in the 4 pixel wide horizontal filter

12:34 <cone-369> ffmpeg Janne Grunau release/7.1:7d1532f75297: vp9: recon: Use emulated edge to prevent buffer overflows

12:36 <BBB> beastd: (and thanks)

12:37 <BBB> wbs: backport done

12:37 <beastd> kurosu: agree we need more automation for this. would definitely give it a try when we setup a git forge for ffmpeg. think it would be good to run fate for topic branches (similar on how it works with patchwork) on a wide subset of platforms/architectures. would of course need suitably isolated fate clients. not sure how much it is a problems with current fate clients setups.

12:38 <beastd> BBB: ok, will give it a try and report back

12:40 <kurosu> Several years ago, I tried asking Intel to provide nodes to perform any hw test. I'm a bit baffled by how much they invest in adding things to ffmpeg, only for this to not be testable by other devs

12:41 <kurosu> (maybe I have to mention 2 other brands, such AMD and Nvidia, to not be taxed of advertisement)

12:42 <beastd> kurosu: yeah, think it would be really cool if all $big_corp would not only donate code but also hw to run it long term

12:44 <beastd> this will also need probably some thought in regards to extending fate. don't think we test much more than our internal stuff and os integration, but i could be wrong. would be good to also do some more integration testing with 3rd party stuff

12:49 <beastd> does someone remember GCC14 fixes for ffmpeg? would maybe be good to backport them to older branches.

13:06 <beastd> Kind of OT, but maybe someone knows by chance (wbs ?). Do most compilers guarantee to only produce output files (objects, libs, executables etc.) only either complete or not at all? (I would expect so, but never checked.)

13:16 <cone-369> ffmpeg Leandro Santiago master:9d9ac8e2ca6b: avfilter/vf_dnn_detect: fix loading anchors when labels file is set

14:21 <beastd> BBB: 3.4, 4.2, 4.3, 4.4, 5.1, 6.1, 7.0, 7.1 <-- all tested on aarch64 without problems. so if the original changes are correct the backports should probably be fine as well

14:25 <beastd> had to make some tradeoffs regarding a bunch of fate tests because of zlib-ng vs fate. but i checked and it seems it's only the usual culprits with embedded png. could not see how it could be affected by vp9 aarch64 changes.

14:26 <beastd> also tested that on current master works fine with the help of my fate .alt file patch set.

14:34 <BBB> cool, tnx

14:59 <fflogger> [editedticket] quinkblack: Ticket #11363 ([avcodec] [Android] MediaCodec decoders/encoders do not work on Pixel 8 Pro (No output buffer available)) updated https://trac.ffmpeg.org/ticket/11363#comment:5

15:08 <fflogger> [editedticket] quinkblack: Ticket #11368 ([ffmpeg] Mediacodec encoding not working) updated https://trac.ffmpeg.org/ticket/11368#comment:4

15:21 <cone-369> ffmpeg Zhao Zhili release/7.1:0151f1daab92: aarch64/vvc: Fix clip in alf

17:05 <fflogger> [editedticket] RandomPerson: Ticket #11368 ([ffmpeg] Mediacodec encoding not working) updated https://trac.ffmpeg.org/ticket/11368#comment:5

18:01 <Marth64[m]> Hi, when's the deadline for 7.1 backports? I had some in mind also. Thank you

18:03 <Marth64[m]> Mostly DVD fixes, a mov.c crash fix, and wrong enum type in demux.c, all in master already

18:24 <nevcairiel> there is never any deadline for bugfixes

18:24 <nevcairiel> point releases arent on a fixed schedule, and even if it doesnt make one, it makes the next

18:25 <nevcairiel> of course first fix it in master, and if its already fixed there, backports are easy for bugfixes

18:27 <Marth64[m]> cool

18:28 <Marth64[m]> I have some FF time tomorrow, I will backport to 7.1.

18:28 <JEEB> `git cherry-pick -x HASH HASH HASH` is your friend

18:29 <Marth64[m]> thx

21:03 <beastd> wbs: today i have backported fate-list-failing locally. as expected no conflicts. you are fine with backporting to all releases listed on our download page?

21:04 <wbs> beastd: I'm a little undecided on that; it's not a pure bugfix, but it also quite safe and harmless... I would raise the question on the mailing list and ask if there are any objections to backporting it

21:06 <beastd> wbs: good point. i just find it useful on releases as well. e.g. for doing backports. will send a mail to the list...