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

[Terje J. Hanssen]

>     On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen
>     <terjejhanssen at gmail.com> wrote:
>
>
>         On 18.07.2024 23:45, Phyllis Smith wrote:
>>         ALL appimages will now be multibit just as if we had checked
>>         these patches into GIT originally.  None will be only 8-bit
>>         and no names will change.
>
>         I did a new test with the current package and Appimage state
>         on openSUSE Leap, but I didn't succed to render to
>         h264-10bit_yuv422p10le.mp4 again. Used Render Video wrench:
>         compression: h264-10bit.mp4, pixels: yuv422p10le
>
>         Any idea why not?
>
>
>         1) With einander current rpm
>
>             cin
>             Cinelerra Infinity - built: Jul 18 2024 03:04:48
>             ......
>             x264 [error]: high10 profile doesn't support 4:2:2
>             [libx264 @ 0x7f09519d9740] Error setting profile high10.
>             FFMPEG::open_encoder err: Invalid argument
>             int FFMPEG::open_encoder(const char*, const char*):
>             open failed
>             libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4
>             Render::render_single: Session finished.
>
>
>         2) With current Multibit Appimage
>
>             ./CinGG-20240630-x86_64-multibit_b6b92655f2c28f7cdd187a66d94816df.AppImage
>             Cinelerra Infinity - built: Jun 30 2024 08:31:40
>             ...........
>             x264 [error]: high10 profile doesn't support 4:2:2
>             [libx264 @ 0x7f0f1c021100] Error setting profile high10.
>             FFMPEG::open_encoder err: Invalid argument
>             int FFMPEG::open_encoder(const char*, const char*):
>             open failed
>             libx264:/run/media/terje/Videoklipp/Cineform/h264-10bit_yuv422p10le_cfhd01.mp4
>             Render::render_single: Session finished.
>
>
>         I did a succesful rendering July 13 (as also mentioned before ):
>
>             ffprobe -hide_banner h264-10bit_yuv422p10le_cfhd01.mp4
>             Input #0, mov,mp4,m4a,3gp,3g2,mj2, from
>             'h264-10bit_yuv422p10le_cfhd01.mp4':
>               Metadata:
>                 major_brand     : isom
>                 minor_version   : 512
>                 compatible_brands: isomiso2avc1mp41
>                 encoder         : Lavf61.1.100
>               Duration: 00:01:11.20, start: 0.000000, bitrate: 9366 kb/s
>               Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 /
>             0x31637661), yuv422p10le(pc, smpte170m/unknown/unknown,
>             top first), 1920x1080 [SAR 1:1 DAR 16:9], 9364 kb/s, 25
>             fps, 25 tbr, 12800 tbn (default)
>                   Metadata:
>                     handler_name    : VideoHandler
>                     vendor_id       : [0][0][0][0]
>
>

@Andrew, @Phyllis,

I've found the explanation:

As seen in my last section from the previous successful rendering above:

     Stream #0:0[0x1](und): Video: h264 (High 4:2:2) (avc1 / 
0x31637661), yuv422p10le(pc,

That is the profile used was indeed h264 (High 4:2:2) or "high422" as 
supported by FFmpeg. That is not "high10" as CinGG reports in the Error 
message..

I have also been able to reconstruct the successful procedure and result 
again using

    Video wrench: compression: h264.mp4, pixels: yuv422p10le

IMO the need to use "h264.mp4" here instead of "h264-10bit.mp4" is 
confusing, because "yuv422p10le" is 10-bit.
So my question is if not also "high422" should be placed among 
"h264-10bit" compression instead?










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