To be honest I hope libtiff build patches, ffmpeg-5.1.patch999 and ffmpeg filters build fix for new ffmpeg will find their way in, because they fix build breakage on Andrea's updated Arch.
Andrew, I need clarification. What do you mean by the above "ffmpeg filters build fix for new ffmpeg"? are you referring to 0002-Fix-build-in-pluginfclient.C-with-ffmpeg-6.0.patch ? I have done a basic look at it and applied it to current ffmpeg-5.1 already rather than 6.0. Is that OK? as it "looks" acceptable to me. Still checking libtiff build patches. My "early quit from filetiff/filetga/filepng" patches might wait for more
testing (notably I hope they does not leak file descriptors or such, I only tested on short, less than minute video).
On further plans ... May be if ffmpeg 6.1 fails to materialize in first half of september we will go with 6.0, preparing new plugin info and such? So far ffmpeg.git was not worse than 5.1 for me but seeking in mkv might be different (it was different in MPlayer).
Other updates might include x265 git (aarch64 stuff, build warning with new nasm fixed), libjpeg-turbo 3.0.0/3.0.1, libtiff 4.5.1, removal of openjpeg (ffmpeg.git removed support for it, and we does not use it directly), adding lcms2 lib so ffmpeg can use it ...
Also, I wonder if optipng run over our icons (or even pngquant, at least on those we have svg source for) might be useful? Standard set of icons weight nearly 8mb and stuffed directly into executable ....
But this is just reminder about ideas I have, my vision and visual taste not good enough for saying definitively about icon quality before/after.
Thanks!
On Sun, Aug 27, 2023 at 11:23 AM Andrew Randrianasulu < [email protected]> wrote:
f_acontrast seems to work on 5.1 with those patches too ...