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

Andrew Randrianasulu randrianasulu at gmail.com
Tue Jul 16 11:46:03 CEST 2024


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



>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20240716/5bf07b8d/attachment.htm>


More information about the Cin mailing list