Den 09.07.2024 01:43, skrev Andrew Randrianasulu:
> ........
>
> well, it was working in the past with configure switches enabling x264/x265 multibit versions compilation. Now x264 should be always multibit and x265 patched manually ... I'll think about something but not sure if there easy way to get this info, esp. for external ffmpeg.
>
> So far simplest way to test seems to be just trying to render 10-bit x265 and see if it works ...
>

Does this mean that the "regular" or basic CinGG version has multibit capability for all encoding (x264 included), except for x265 which has only 8-bit here?
And on the other hand, CinGG-Multibit has multibit capability for all encoding (x265 included), except for x264 which has only 8-bit here?
 
Does this also mean that it is not possible to make a "smart", common CinGG version that has multibit capability for all encoding, x264 and x265 included?


Den 16.07.2024 09:24, skrev Andrew Randrianasulu via Cin:


вт, 16 июл. 2024 г., 10:20 Andrea paz via Cin <cin@lists.cinelerra-gg.org>:
Let's wait before changing the name. There is a risk that playback on
the timeline (which is already problematic in CinGG) will be less
efficient.

As far as I understand x265 is *encoder* so playback performance should stay roughly the same ....


Let me do some more testing and even better would be to do
some more with less performing hardware (which I don't have). The
confusion involved with the name change could also be problematic. I'd
love the opinions of other users as well.
--


I wonder why I didn't get the following encoding formats to work

0    av1_svt_yuv420p_cfhd01.webm
0    av1_vaapi_yuv420p_cfhd01.webm
0    av1_yuv422p10le_cfhd01.webm

And won't it be possible to enable Intel qsv etc. hwaccel support with CinGG's "internal ffmpeg", when it is available for my system ffmpeg?