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 <[email protected]> wrote: > > On Sun, Jul 21, 2024 at 1:03 PM Terje J. Hanssen <[email protected]> >> 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? > > > > > > > > > > > >
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
