Den 12.07.2024 01:02, skrev Phyllis Smith:
Catching up on this thread with some trivial commentary on my part.

I looked into which pixel formats current ffmpeg-7 encoders in question do support as follows:  "QUOTE from Terje"
The "pixel formats" that CinGG supports with whatever ffmpeg version is currently being used, is shown in the Render Menu when you click on the Video wrench.  There is a box labeled "Pixels" and when you click on the down arrow next to the box, it displays all of the supported formats so you do not have to reference the ffmpeg documentation externally.

Thank you, that was clarifying using CinGG, and I did some browsing tests, additional selected container format and compression (?)
It's late, so please excuse and correct me if I did miss something during a quick comparison with my last post and could not see these encoders
av1_nvenc, av1_qsv, av1_amf, mpeg2_qsv (hwaccel) and cfhd
 
So we keep the 8-bit because it is more efficient (1 word vs 2 words)? Are there other reasons? Wouldn't it be less confusing to just have the multibit?  "QUOTE from Andrea"
As long as we have the capability to support older operating systems, smaller computers, 32-bit, and older cameras, there does not seem to be any reason to eliminate the non-multibit version.  Now there is still a choice and there may be reasons to not just have the multibit version from what I read based on the multibit taking more CPU (I have not tested this).  It does not seem confusing to me -- probably newer users with newer systems will automatically pick the multibit version.

less work for both developers and users "QUOTE from Terje"
Because I sometimes do multiple builds in a single session, the extra time it takes to compile the multibit version is detrimental for me.  On the other hand, creating a single AppImage multibit version of the generally newer operating system is only done by me once a month or less and no work at all.  BTW, the    CinGG-20240630-x86_64-older-distros-multibit.AppImage    was just a request from a Red Hat user (like Fedora) who wanted Intel graphics capability that I just happened to have set up. I am not sure if it is much used.  And I do not see any additional work needed by users -- they should just pick that single multibit version.

Ok, no extra maintaining job. I have up to now installed both versions of the belief that only Multibit did support 10bit or higher color depth (esp. x265).

So to clarify further, is also einander's CinGG package version (rpm for me) identical with the Multibit version (earlier Cinx)?
It would also be useful with an updated list over supported formats, codecs and bit-rates, based on CinGG's internal ffmpeg engine. Some codecs like Cineform is not mentioned in the current manual. "QUOTE Terje"
Accuracy and being up to date on ffmpeg documentation is really best done by their team.  Those using AppImage may not have ffmpeg actually installed on their computer, but all of the ffmpeg documentation is readily available on the internet.  Duplication is not a good idea as it may not get updated.

CineformHD is only mentioned in the "Overview on Formats and Codecs" appendix "QUOTE Andrea"
There is an index entry in the Manual of "codec".  Maybe adding "Overview on Formats and Codecs" could be another index?