вт, 16 июл. 2024 г., 12:34 Terje J. Hanssen <terjejhanssen@gmail.com>:
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?


yes, I think ....

And on the other hand, CinGG-Multibit has multibit capability for all encoding (x265 included), except for x264 which has only 8-bit here?


no, x264 should be full featured (8/10 bit) in all variants of cingg compiled with internal x264/ffmpeg ...
 
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?


this should be current *-multibit version, but as Andrea noticed it might be slower at regular x265 8bit encodes.

I looked up doom9 forums and it seems even modern CPUs struggle with 4k x265 encoder on slow preset

too many pages

http://forum.doom9.net/showthread.php?t=176545
"Which processor to encode x265 4K ?"

openbenchmarking page
https://openbenchmarking.org/test/pts/x265

few systems break 30 fps barrier ....




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? 


in theory yes, just figure out that switch you need to pass to ffmpeg for that (ffmpeg should print it in its banner ) and add it to  FFMPEG_EXTRA_CFG=" --your-switch --your-second-switch" environmental variable set via export command before you run autogen.sh/configure/make