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?
--
Cin mailing list
[email protected]
https://lists.cinelerra-gg.org/mailman/listinfo/cin
