[Cin] Updated CinGG release for downloading the AppImage

Andrew Randrianasulu randrianasulu at gmail.com
Sat Nov 6 00:29:47 CET 2021


On Saturday, November 6, 2021, Terje J. Hanssen via Cin <
cin at lists.cinelerra-gg.org> wrote:

>
>
> Den 05.11.2021 11:55, skrev Andrea paz:
>
>> @Terje
>> If I understand correctly, you used only the h264.mp4 and h265.mp4
>> presets, changing the "Pixels" option from "420 8-bit" to "422 10-bit"
>> each time. Also, try using the 8, 10 and 12-bit h265 presets; they are
>> Andrew's new ones that work for me in the non-multibit version.
>> I've tried non-multibit and I can render h264.mp4 at 8 and 10-bit and
>> h265.mp4 at 8 and 10-bit. In short, in my case the non-multibit
>> version always behaves as a sum of multibit and non-multibit.
>>
>>
> @Andrea and All
> I had a look into the Manual: Modifying FFmpeg Format Options inside
> CINELERRA-GG
> Figure 9.2: FFmpeg wrench, video preset, view and format options
> https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifyi
> ng_FFmpeg_Format_Opt.html
>
> and tried to indicate cin version and parameters in my test file names (no
> warranty the syntax is quite consistent), i.e
>
> hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4
> File > Render | File format: FFMPEG mp4 | Video Wrench
> > Video Preset | Compression: h264-10bit.mp4 | Pixels: yuv422p10le
>
> While this rendered OK on one of my workstation, another installation
> wouldn't render at all with the following
> Message log:
> virtual void Render::handle close event(int):
>  Create new at labels checked, but no labels
> (or other Failure)



guess in this case you (accidently?) selected rendering option making new
file at each label (3rd radiobutton out of four) instead of rendering whole
file/ in-out region....


>
> ------------------------
>
> Regarding ffmpeg (before going further with testing):
> Is it a somewhat correct understanding that rendering (encoding) inside
> Cin-GG (AppImage) works as a GUI front-end for its statical linked ffmepg?


usually yes, you can try to build it differently

./configure --help | grep thirdparty
  --with-thirdparty use thirdparty build (yes)

but this usually will have chance to work only if system ffmpeg at same
version as internal copy... Also, internal ffmpeg patched quite heavily...

>
> Even if my local system's ffmpeg is not used, I think 3 ffmpeg commands
> (applied from stackexchange) possibly add understanding also for rendering
> via Cin-GG:


> ---------------------
> 1) To see what pixel formats and bit depths are supported by libx264:
>
> ffmpeg -h encoder=libx264 | grep Supported
>
> ffmpeg version 4.4 Copyright (c) 2000-2021 the FFmpeg developers
>   built with gcc 7 (SUSE Linux)
>  [ffmpeg text header .........]  --enable-libx264 --enable-libx265
> --enable-librtmp --enable-libxvid
>
>     Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p
> yuvj444p nv12 nv16 nv21 yuv420p10le yuv422p10le yuv444p10le nv20le gray
> gray10le
>
> (It seems to me that both libx264 and libx265 are enabled in this case)
>
> Is it possible that Cin and Cin-multi have statical linked ffmpeg with
> both libx enabled?



see above, there is dependency in thirdparty/Makefile so x264/x265 built
first, and then ffmpeg built  pointed at those libs. Still, I need to
double-check for possible missing static switch.. On termux x265 built with
only 8 bit depth for system, so I need patch and CinGg renders h265/h264,
so I guess this  part works here...

>
> ----------------
> 2) and by libx265, here with suppressed ffmpeg text header (-v quiet):
>
> ffmpeg -v quiet -h encoder=libx265 | grep Supported
>
>     Supported pixel formats: yuv420p yuvj420p yuv422p yuvj422p yuv444p
> yuvj444p gbrp yuv420p10le yuv422p10le yuv444p10le gbrp10le yuv420p12le
> yuv422p12le yuv444p12le gbrp12le gray gray10le gray12le
>
> In both cases 10-bit pixel formats are those that end with 10le.
>
> ---------------
> 3) ffmpeg with the -codec switch, you will get an output of (all) codecs
> it understands. The codecs are prefaced with letter codes that describe
> their function. 'D' means Decode, meaning that particular codec has
> decoding capability (read). While 'E' means Encode, or compiling/writing
> capability using that particular codec.
>
> ffmpeg -v quiet -codecs | egrep "x264|x265"
>
>  DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10
> (decoders: h264 h264_v4l2m2m h264_qsv ) (encoders: libx264 libx264rgb
> h264_qsv h264_v4l2m2m h264_vaapi )
>  DEV.L. hevc                 H.265 / HEVC (High Efficiency Video Coding)
> (decoders: hevc hevc_qsv hevc_v4l2m2m ) (encoders: libx265 hevc_qsv
> hevc_v4l2m2m hevc_vaapi )
>
>
> ----------------
>
> Terje J. H
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20211106/49701956/attachment.htm>


More information about the Cin mailing list