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

[Phyllis Smith]

When I read ffmepg Profile section, it stated "The -profile:v option limits
the output to a specific H.264 profile. You usually do not need to use this
option and the r*ecommendation is to omit setting the profile* which will
allow x264 to automatically select the appropriate profile.  So I will
eliminate the "profile=high10" from the h264-10bit.mp4 format and then it
will work.

On Sun, Jul 21, 2024 at 3:58 PM Terje J. Hanssen <terjejhanssen at gmail.com>
wrote:

>
> 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/9c3e588e/attachment-0001.htm>