[Cin] How to identify if a running CinGG is the Regular or Multibit version?

[Terje J. Hanssen]

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 havethe 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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240712/1121bbb7/attachment-0001.htm>