Updated CinGG release for downloading the AppImage
The October 31, 2021 CinGG releases are at: https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64.AppImage https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64-older_distros... https://cinelerra-gg.org/download/images/CinGG-20211031-multibit.AppImage https://cinelerra-gg.org/download/images/CinGG-20211031-i386.AppImage *GIT for Cinelerra-GG has the following changes from 10/01/2021-10/31/2021* The instructions for using AppImage in the file, *README_appimage.txt*, was updated by *Terje*. *Cineform, DPX, MXF *additional render formats have been provided as used in ffmpeg by *Andrea*. *Title video plugin* now correctly fades in/out as reported by *Camille.* This bug had been around a very long time (see BT #559) with the fix now done by a Freelancer. Many *plugins were being reloaded* in the AppImage on every start which could take awhile on some computers. *MatN* has expertly fixed this and changed that of the Cinelerra_plugins also. Note that any time a new release/build is started for the first time, it will always reload the plugins but each subsequent usage of that image will no longer require reloads as long as you use the same .bcast5. *Andrew-R contributions:* Opus and aom thirdparty libraries have had the examples and extras deleted to save build time. *In support of Android/Termux* CinGG compile, patches for libwepb and libaom have been added. Defaults for mxf render format have now been established. *Hungarian translation* as created using google with a 90% automated procedure is now available. To use, keyin the following in a window: LANGUAGE=hu ./CinGG-20211031-x86_64.AppImage
Il giorno dom 31 ott 2021 alle ore 21:39 Phyllis Smith via Cin <[email protected]> ha scritto:
The October 31, 2021 CinGG releases are at:
https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64.AppImage https://cinelerra-gg.org/download/images/CinGG-20211031-x86_64-older_distros... https://cinelerra-gg.org/download/images/CinGG-20211031-multibit.AppImage https://cinelerra-gg.org/download/images/CinGG-20211031-i386.AppImage
GIT for Cinelerra-GG has the following changes from 10/01/2021-10/31/2021 The instructions for using AppImage in the file, README_appimage.txt, was updated by Terje. Cineform, DPX, MXF additional render formats have been provided as used in ffmpeg by Andrea. Title video plugin now correctly fades in/out as reported by Camille. This bug had been around a very long time (see BT #559) with the fix now done by a Freelancer. Many plugins were being reloaded in the AppImage on every start which could take awhile on some computers. MatN has expertly fixed this and changed that of the Cinelerra_plugins also. Note that any time a new release/build is started for the first time, it will always reload the plugins but each subsequent usage of that image will no longer require reloads as long as you use the same .bcast5. Andrew-R contributions: Opus and aom thirdparty libraries have had the examples and extras deleted to save build time. In support of Android/Termux CinGG compile, patches for libwepb and libaom have been added. Defaults for mxf render format have now been established. Hungarian translation as created using google with a 90% automated procedure is now available. To use, keyin the following in a window: LANGUAGE=hu ./CinGG-20211031-x86_64.AppImage
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
All perfect installation and appimage. Thank you. Two questions: 1- I also tried to build OpenCV along with the source and had no errors. But the plugins don't appear in the plugins list. Instead putting manually the plugins in ".../bin/plugins" everything works normally. (PS: OpenCV has been updated recently, is it possible to create the most updated copies of the plugins?) 2- I don't really understand the multibit version.Why put both the regular version and the multibit version? Are there things that work with one and not the other version? PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to me.
Den 02.11.2021 11:53, skrev Andrea paz via Cin:
All perfect installation and appimage. Thank you. Two questions: 1- I also tried to build OpenCV along with the source and had no errors. But the plugins don't appear in the plugins list. Instead putting manually the plugins in ".../bin/plugins" everything works normally. (PS: OpenCV has been updated recently, is it possible to create the most updated copies of the plugins?) 2- I don't really understand the multibit version.Why put both the regular version and the multibit version? Are there things that work with one and not the other version?
PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to me.
Re 2- I am not sure about the later route to Cin "multi-bit", but initial the Cin "10-bit" (Cinx) was based on x265 (i.e for Blu-ray rendering), while the regular Cin is and was 8-bit based on x264, as clarified by Phyllis in this earlier thread https://lists.cinelerra-gg.org/pipermail/cin/2019-January/000121.html Terje J. H
CinX
Recently Andrew has worked on many patches to extend the encoding of CinGG; for example the "compile_multibit_X265.txt" patch. I guess compiling CinGG with this patch is equivalent to using CinGG-multibit.AppImage. I produced "test-multibit1.mp4" with the multibit appimage and I produced "test-multibit2.mp4" with CinGG compiled WITHOUT the patch. For both I used the preset: "h265-10bit.mp4". The results are the same: both files are encoded correctly at 10-bit. There is something I can't understand about the functioning of the patches I tried!
still a bit strange, shouldn't encoder string from mediainfo indicate 8+10+12 bit instead of just 10? 'x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit' try to encode 8 and/or 12 bit h265 with normal and multibit build?? full mediainfo: $ mediainfo ~/storage/downloads/Browser/test-multibit1.mp4 General Complete name : /data/data/com.termux/files/home/storage/downloads/Browser/test-multibit1.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) File size : 1.66 MiB Duration : 35 s 280 ms Overall bit rate mode : Variable Overall bit rate : 395 kb/s Writing application : Lavf58.76.100 Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Format Range@L3@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Duration : 35 s 240 ms Bit rate : 386 kb/s Width : 854 pixels Height : 480 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.038 Stream size : 1.62 MiB (98%) Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit Encoding settings : cpuid=1111039 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=854x480 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=160:161 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass Color range : Full Color primaries : BT.2020 Transfer characteristics : BT.2020 (10-bit) Matrix coefficients : BT.2020 constant Codec configuration box : hvcC Audio ID : 2 Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Duration : 35 s 280 ms Source duration : 35 s 301 ms Source_Duration_LastFrame : -5 ms Bit rate mode : Variable Bit rate : 2 278 b/s Maximum bit rate : 128 kb/s / 128 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 46.875 FPS (1024 SPF) Compression mode : Lossy Stream size : 9.81 KiB (1%) Source stream size : 9.82 KiB (1%) Language : Italian Default : Yes Alternate group : 1 mdhd_Duration : 35280 $ On Tuesday, November 2, 2021, Andrea paz via Cin <[email protected]> wrote:
Sorry, I forgot the videos.
ah, apparently only command line x265 encoder prints this line as I remember it: x265 [error]: No input file. Run x265 --help for a list of options. $ thirdparty/x265_3.5/8bit/x265 --version x265 [info]: HEVC encoder version 3.5+1-f0c1022b6 x265 [info]: build info [Linux][clang 12.0.0][32 bit][noasm] 8bit+10bit+12bit x265 [info]: using cpu capabilities: none! confusing! On Tuesday, November 2, 2021, Andrew Randrianasulu <[email protected]> wrote:
still a bit strange, shouldn't encoder string from mediainfo indicate 8+10+12 bit instead of just 10?
'x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit'
try to encode 8 and/or 12 bit h265 with normal and multibit build??
full mediainfo:
$ mediainfo ~/storage/downloads/Browser/test-multibit1.mp4 General Complete name : /data/data/com.termux/files/home/storage/downloads/ Browser/test-multibit1.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) File size : 1.66 MiB Duration : 35 s 280 ms Overall bit rate mode : Variable Overall bit rate : 395 kb/s Writing application : Lavf58.76.100
Video ID : 1 Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Format Range@L3@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Duration : 35 s 240 ms Bit rate : 386 kb/s Width : 854 pixels Height : 480 pixels Display aspect ratio : 16:9 Frame rate mode : Constant Frame rate : 25.000 FPS Color space : YUV Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.038 Stream size : 1.62 MiB (98%) Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit Encoding settings : cpuid=1111039 / frame-threads=4 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=854x480 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=0 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=255 / sar-width / : / sar-height=160:161 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass Color range : Full Color primaries : BT.2020 Transfer characteristics : BT.2020 (10-bit) Matrix coefficients : BT.2020 constant Codec configuration box : hvcC
Audio ID : 2 Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Duration : 35 s 280 ms Source duration : 35 s 301 ms Source_Duration_LastFrame : -5 ms Bit rate mode : Variable Bit rate : 2 278 b/s Maximum bit rate : 128 kb/s / 128 kb/s Channel(s) : 2 channels Channel layout : L R Sampling rate : 48.0 kHz Frame rate : 46.875 FPS (1024 SPF) Compression mode : Lossy Stream size : 9.81 KiB (1%) Source stream size : 9.82 KiB (1%) Language : Italian Default : Yes Alternate group : 1 mdhd_Duration : 35280
$
On Tuesday, November 2, 2021, Andrea paz via Cin < [email protected]> wrote:
Sorry, I forgot the videos.
Den 02.11.2021 17:20, skrev Andrea paz via Cin:
try to encode 8 and/or 12 bit h265 with normal and multibit build?? Test done several times before. Each result is the same for multibit and unpatched build. (I think it's better that way too, with everything always working. As long as the same happens to others....)
I recorded a 10-bit ProsRes HQ file (hd01.mov) in 2016 and rendered it to mp4 with the 2019 packaged rpm Cin (h264) and CinX (h265) on openSUSE Leap. Now I've tested to render it correspondigly with the latest Cin regular and Cin-multi appimage versions. ---------- For me it seems that Cin is able to render both 8-bit and 10-bit with h264, while only CinX (multibit) is able to render with h265 compression. For this test I've used File>Render | Video Wrench to select Compression and Pixels (color depth), and have not explored other format details especially. Attach below some file properies and extracted output from Mediainfo: du -sh hd01* 70M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 92M hd01_cin_ffmpeg_h264_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 20M hd01_cinx_ffmpeg_h265_yuv422p10le.mp4 ls -la hd01* -rw-r--r-- 1 terje users 73189134 nov. 4 19:04 hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 -rw-r--r-- 1 terje users 82863073 nov. 4 19:30 hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 -rw-r--r-- 1 terje users 96422147 feb. 2 2019 hd01_cin_ffmpeg_h264_yuv422p10le.mp4 -rw-r--r-- 1 terje users 27078948 nov. 4 19:47 hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 -rw-r--r-- 1 terje users 20114981 feb. 4 2019 hd01_cinx_ffmpeg_h265_yuv422p10le.mp4 -rwxrwxrwx 1 terje users 1786412681 feb. 24 2016 hd01.mov file hd01* hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] hd01_cin_ffmpeg_h264_yuv422p10le.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] hd01_cinx_ffmpeg_h265_yuv422p10le.mp4: ISO Media, MP4 Base Media v1 [IS0 14496-12:2003] hd01.mov: Apple QuickTime movie (unoptimized) ================================ mediainfo hd01.mov | egrep "Codec|Format|Chroma|Bit" Format : QuickTime Format/Info : Original Apple specifications Format : ProRes Format version : Version 0 Format profile : 422 HQ Codec ID : apch Bit rate mode : Variable Bit rate : 182 Mb/s Chroma subsampling : 4:2:2 Bits/(Pixel*Frame) : 3.513 Format : PCM Format settings : Little / Signed Codec ID : lpcm Bit rate mode : Constant Bit rate : 18.4 Mb/s Bit depth : 24 bits ==================== mediainfo hd01_cin_ffmpeg_h264_yuv422p10le.mp4 | egrep "Codec|Format|Chroma|Bit" Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:2:2@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Format settings, GOP : M=4, N=25 Codec ID : avc1 Codec ID/Info : Advanced Video Coding Bit rate : 10.5 Mb/s Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.202 Codec configuration box : avcC Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Bit rate mode : Variable Bit rate : 328 kb/s ================== mediainfo hd01_cinx_ffmpeg_h265_yuv422p10le.mp4 | egrep "Codec|Format|Chroma|Bit" Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Format Range@L4@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Bit rate : 1 924 kb/s Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.037 Codec configuration box : hvcC Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Bit rate mode : Variable Bit rate : 328 kb/s ========================== mediainfo hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 | egrep "Codec|Format|Chroma|Bit" Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) Format : AVC Format/Info : Advanced Video Codec Format profile : High 10@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Format settings, GOP : M=4, N=25 Codec ID : avc1 Codec ID/Info : Advanced Video Coding Bit rate : 7 889 kb/s Chroma subsampling : 4:2:0 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.152 Codec configuration box : avcC Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Bit rate mode : Variable Bit rate : 328 kb/s ================================== mediainfo hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 | egrep "Codec|Format|Chroma|Bit" Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) Format : AVC Format/Info : Advanced Video Codec Format profile : High 4:2:2@L4 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference frames : 4 frames Format settings, GOP : M=4, N=25 Codec ID : avc1 Codec ID/Info : Advanced Video Coding Bit rate : 8 976 kb/s Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.173 Codec configuration box : avcC Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Bit rate mode : Variable Bit rate : 328 kb/s ========================================== mediainfo hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 | egrep "Codec|Format|Chroma|Bit" Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/mp41) Format : HEVC Format/Info : High Efficiency Video Coding Format profile : Format Range@L4@Main Codec ID : hev1 Codec ID/Info : High Efficiency Video Coding Bit rate : 2 707 kb/s Chroma subsampling : 4:2:2 Bit depth : 10 bits Bits/(Pixel*Frame) : 0.052 Codec configuration box : hvcC Format : AAC LC Format/Info : Advanced Audio Codec Low Complexity Codec ID : mp4a-40-2 Bit rate mode : Variable Bit rate : 328 kb/s =================================== Terje J. H
@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. @all I'm thinking that it's the fault of my system that "gets" the 10-bit even when it shouldn't.... When I compile a new CinGG I usually delete the old cinelerra5 directory and then do a git clone. That way it shouldn't encounter any residue from the previous installation. Am I wrong? Maybe the fact that I compile not as root (except few times I use Valgrind or other tests) can be the cause of the behavior of my CinGGs?
On Friday, November 5, 2021, Andrea paz via Cin <[email protected]> wrote:
@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. @all I'm thinking that it's the fault of my system that "gets" the 10-bit even when it shouldn't....
in https://www.cinelerra-gg.org/bugtracker/view.php?id=596 you can see use of LD_DEBUG=libs, where appimage apparently tries to initialize libx265_main10/12.so system files lately (at encodiing stage?), so may be it was not visible to initial ldd? I wonder if those files come from appimage or real system? you and Terje can try to compare output of this LD_DEBUG=libs path_to_cin command for 10/12 bit h265 encoding.. Not sure if package manager will allow you to delete system-wide x265 development files (so Cin will have nothing but her own x265.a lib to use at least after self-build). It seems even with static switch some shared system libs are used (may be because there was no static a archives in some distro packages?)..
When I compile a new CinGG I usually delete the old cinelerra5 directory and then do a git clone. That way it shouldn't encounter any residue from the previous installation. Am I wrong? Maybe the fact that I compile not as root (except few times I use Valgrind or other tests) can be the cause of the behavior of my CinGGs? -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
@Andrea You should not have to compile as root. If there is a difference in behaviour between user and root build, it should be fixed.
@Andrew, both static and AppImage do not include all libraries. If static included enough, maybe the AppImage would not be needed, if newer system libraries are backwards compatible enough. On the other hand, it would get much bigger. MatN
Tried starting CinGG (build = non-multibit) with LD_DEBUG=libs; then rendered with the h265-12bit.mp4 preset. For the little I understand about it, it seems that it really looks for libx265 on the system and not in thirdparty. See x265.txt file.
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/Modifying_FFmpeg_Format... 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) ------------------------ 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? 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? ---------------- 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
On Saturday, November 6, 2021, Terje J. Hanssen via Cin < [email protected]> 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 [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen via Cin <[email protected] <mailto:[email protected]>> 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/Modifying_FFmpeg_Format... <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_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....
@Andrew Thx, that's right - I don't know why or how the Render "Make new file box" was checked on my MSI workstation. Unchecked it and the above file rendered ok. A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons. One render option combination that Cin-gg regular reported error message (invalid or not supported), was as shown on the screenshot h265-10bit.mp4 compression and yuv422p10le pixels Is this correct? @Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows: du -sh hd01.mov hd01*app*.mp4 1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4 @"Manual" I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively? ----------------- Terje J. H
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen via Cin < [email protected] <mailto:[email protected]>> 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 <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modify ing_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....
@Andrew Thx, that's right - I don't know why or how the Render "Make new file box" was checked on my MSI workstation. Unchecked it and the above file rendered ok.
A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons.
guess: because different Cin instances used different themes?
One render option combination that Cin-gg regular reported error message (invalid or not supported), was as shown on the screenshot h265-10bit.mp4 compression and yuv422p10le pixels Is this correct?
well, it was motivation for me to write my patches, but apparently not all systems behave like this...
@Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
@"Manual" I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively?
----------------- Terje J. H
Den 06.11.2021 17:15, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected] <mailto:[email protected]>> wrote:
Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen via Cin <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> 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/Modifying_FFmpeg_Format... <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html> <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format... <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_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....
@Andrew Thx, that's right - I don't know why or how the Render "Make new file box" was checked on my MSI workstation. Unchecked it and the above file rendered ok.
A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons.
guess: because different Cin instances used different themes?
One render option combination that Cin-gg regular reported error message (invalid or not supported), was as shown on the screenshot h265-10bit.mp4 compression and yuv422p10le pixels Is this correct?
well, it was motivation for me to write my patches, but apparently not all systems behave like this...
@Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
The file quality (sharpness) looks fine against the input hd01.mov file, the file colors varies a bit between greenish and yellow-brownish. I didn't change the default project setting, just loaded the hd01.mov file once, and rendered all files from it. The default Setting > Format color model is RGBA-8bit Obviously it should have been set to the higher RGB(A)-Float for this 10-bit 422 ProRes HQ file format? Terje J. H
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 06.11.2021 17:15, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen via Cin < [email protected] <mailto:[email protected]>> 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 <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modify ing_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....
@Andrew Thx, that's right - I don't know why or how the Render "Make new file box" was checked on my MSI workstation. Unchecked it and the above file rendered ok.
A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons.
guess: because different Cin instances used different themes?
One render option combination that Cin-gg regular reported error message (invalid or not supported), was as shown on the screenshot h265-10bit.mp4 compression and yuv422p10le pixels Is this correct?
well, it was motivation for me to write my patches, but apparently not all systems behave like this...
@Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
The file quality (sharpness) looks fine against the input hd01.mov file, the file colors varies a bit between greenish and yellow-brownish.
I didn't change the default project setting, just loaded the hd01.mov file once, and rendered all files from it. The default Setting > Format color model is RGBA-8bit Obviously it should have been set to the higher RGB(A)-Float for this 10-bit 422 ProRes HQ file format?
Terje J. H
I think yes, there even was bugreport about it but back in time it was said fine-tuning project settings (from auto/default at media load) is user responsibility...
Den 06.11.2021 19:09, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected] <mailto:[email protected]>> wrote:
[.............]
@Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
The file quality (sharpness) looks fine against the input hd01.mov file, the file colors varies a bit between greenish and yellow-brownish.
I didn't change the default project setting, just loaded the hd01.mov file once, and rendered all files from it. The default Setting > Format color model is RGBA-8bit Obviously it should have been set to the higher RGB(A)-Float for this 10-bit 422 ProRes HQ file format?
Terje J. H
I think yes, there even was bugreport about it but back in time it was said fine-tuning project settings (from auto/default at media load) is user responsibility...
I have re-rendered all h65 files with Setting>Format>Color model=RGB-Float or RGBA-Float and OK. I'm not sure this is right or wrong, because all h265 file sizes and Bit rate become still practical the same size as with RGBA-8. Here two examples: du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26240 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26268 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 And here follows comparision (diff) of Mediainfo output for the same files: diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo 2c2 < Complete name : hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 ---
Complete name : hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 9c9 < Overall bit rate : 3 015 kb/s
Overall bit rate : 3 018 kb/s 20c20 < Bit rate : 2 685 kb/s
Bit rate : 2 687 kb/s 28c28 < Bit depth : 8 bits
Bit depth : 10 bits 34,35c34,35 < Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 8bit < Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass 51c51 < Bit rate : 327 kb/s
Bit rate : 328 kb/s 58,59c58,59 < Stream size : 2.78 MiB (11%) < Source stream size : 2.78 MiB (11%)
Stream size : 2.79 MiB (11%) Source stream size : 2.79 MiB (11%)
---------------------------- Terje J. H
On Sunday, November 7, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 06.11.2021 19:09, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected]
<mailto:[email protected]>> wrote:
[.............]
@Andrea
I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
The file quality (sharpness) looks fine against the input hd01.mov file, the file colors varies a bit between greenish and yellow-brownish.
I didn't change the default project setting, just loaded the hd01.mov file once, and rendered all files from it. The default Setting > Format color model is RGBA-8bit Obviously it should have been set to the higher RGB(A)-Float for this 10-bit 422 ProRes HQ file format?
Terje J. H
I think yes, there even was bugreport about it but back in time it was said fine-tuning project settings (from auto/default at media load) is user responsibility...
I have re-rendered all h65 files with Setting>Format>Color model=RGB-Float or RGBA-Float and OK. I'm not sure this is right or wrong, because all h265 file sizes and Bit rate become still practical the same size as with RGBA-8.
Here two examples:
du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26240 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26268 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
And here follows comparision (diff) of Mediainfo output for the same files:
diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo 2c2 < Complete name : hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 ---
Complete name : hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 9c9 < Overall bit rate : 3 015 kb/s
Overall bit rate : 3 018 kb/s 20c20 < Bit rate : 2 685 kb/s
Bit rate : 2 687 kb/s 28c28 < Bit depth : 8 bits
Bit depth : 10 bits 34,35c34,35 < Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 8bit < Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass
Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass 51c51 < Bit rate : 327 kb/s
Bit rate : 328 kb/s 58,59c58,59 < Stream size : 2.78 MiB (11%) < Source stream size : 2.78 MiB (11%)
Stream size : 2.79 MiB (11%) Source stream size : 2.79 MiB (11%)
----------------------------
Terje J. H
well, considering predictability of bitrate this is good, but may be not very good for comparing max possible quality of encodings... in ffmpeg/video/h265.mp4 profile I can see cin_quality=-1 setting. This setting absent from h264.mp4 profile. Try to comment it out before rendering? May be we can/should create unconstrained (bitrate-wise) profiles for h265, too...
Den 07.11.2021 04:55, skrev Andrew Randrianasulu:
On Sunday, November 7, 2021, Terje J. Hanssen <[email protected] <mailto:[email protected]>> wrote:
Den 06.11.2021 19:09, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen <[email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>>> wrote:
[.............]
@Andrea I succeeded to rendered further combinations and cleaned up my file name syntax as follows:
du -sh hd01.mov hd01*app*.mp4
1,7G hd01.mov (input 10bit ProRes HQ file) -------------------------- 70M hd01_cin_appimage_ffmpeg_h264-10bit_yuv422p10le.mp4 72M hd01_cin_appimage_ffmpeg_h264_yuv420p.mp4 80M hd01_cin_appimage_ffmpeg_h264_yuv422p10le.mp4 82M hd01_cin_appimage_ffmpeg_h264_yuv422p.mp4 0 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 (failed) 26M hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26M hd01_cin_appimage_ffmpeg_h265_yuv422p.mp4 -------------------------- 26M hd01_cin-multi_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265-12bit_yuv422p12le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p10le.mp4 26M hd01_cin-multi_appimage_ffmpeg_h265_yuv422p.mp4
but how they look visually? I found it a bit strange how h264 compresses to different sizes yet h265 is all the same.. you tried with rgb(a) - float project setting in all cases, yes?
The file quality (sharpness) looks fine against the input hd01.mov file, the file colors varies a bit between greenish and yellow-brownish.
I didn't change the default project setting, just loaded the hd01.mov file once, and rendered all files from it. The default Setting > Format color model is RGBA-8bit Obviously it should have been set to the higher RGB(A)-Float for this 10-bit 422 ProRes HQ file format?
Terje J. H
I think yes, there even was bugreport about it but back in time it was said fine-tuning project settings (from auto/default at media load) is user responsibility...
I have re-rendered all h65 files with Setting>Format>Color model=RGB-Float or RGBA-Float and OK. I'm not sure this is right or wrong, because all h265 file sizes and Bit rate become still practical the same size as with RGBA-8.
Here two examples:
du -sk hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 26240 hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 26268 hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4
And here follows comparision (diff) of Mediainfo output for the same files:
diff hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mediainfo hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mediainfo 2c2 < Complete name : hd01_cin_appimage_ffmpeg_h265-10bit_yuv422p.mp4 --- > Complete name : hd01_cin-multi_rgba-float_appimage_ffmpeg_h265-10bit_yuv422p10le.mp4 9c9 < Overall bit rate : 3 015 kb/s --- > Overall bit rate : 3 018 kb/s 20c20 < Bit rate : 2 685 kb/s --- > Bit rate : 2 687 kb/s 28c28 < Bit depth : 8 bits --- > Bit depth : 10 bits 34,35c34,35 < Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 8bit < Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=255 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass --- > Writing library : x265 3.5+1-f0c1022b6:[Linux][GCC 10.2.1][64 bit] 10bit > Encoding settings : cpuid=1111039 / frame-threads=3 / wpp / no-pmode / no-pme / no-psnr / no-ssim / log-level=2 / input-csp=2 / input-res=1920x1080 / interlace=0 / total-frames=0 / level-idc=0 / high-tier=1 / uhd-bd=0 / ref=3 / no-allow-non-conformance / no-repeat-headers / annexb / no-aud / no-hrd / info / hash=0 / no-temporal-layers / open-gop / min-keyint=30 / keyint=30 / gop-lookahead=0 / bframes=4 / b-adapt=2 / b-pyramid / bframe-bias=0 / rc-lookahead=20 / lookahead-slices=6 / scenecut=40 / hist-scenecut=0 / radl=0 / no-splice / no-intra-refresh / ctu=64 / min-cu-size=8 / no-rect / no-amp / max-tu-size=32 / tu-inter-depth=1 / tu-intra-depth=1 / limit-tu=0 / rdoq-level=0 / dynamic-rd=0.00 / no-ssim-rd / signhide / no-tskip / nr-intra=0 / nr-inter=0 / no-constrained-intra / strong-intra-smoothing / max-merge=3 / limit-refs=1 / no-limit-modes / me=1 / subme=2 / merange=57 / temporal-mvp / no-frame-dup / no-hme / weightp / no-weightb / no-analyze-src-pics / deblock=0:0 / sao / no-sao-non-deblock / rd=3 / selective-sao=4 / early-skip / rskip / no-fast-intra / no-tskip-fast / no-cu-lossless / b-intra / no-splitrd-skip / rdpenalty=0 / psy-rd=2.00 / psy-rdoq=0.00 / no-rd-refine / no-lossless / cbqpoffs=0 / crqpoffs=0 / rc=crf / crf=28.0 / qcomp=0.60 / qpstep=4 / stats-write=0 / stats-read=0 / ipratio=1.40 / pbratio=1.30 / aq-mode=2 / aq-strength=1.00 / cutree / zone-count=0 / no-strict-cbr / qg-size=32 / no-rc-grain / qpmax=69 / qpmin=0 / no-const-vbv / sar=1 / overscan=0 / videoformat=5 / range=1 / colorprim=9 / transfer=14 / colormatrix=10 / chromaloc=0 / display-window=0 / cll=0,0 / min-luma=0 / max-luma=1023 / log2-max-poc-lsb=8 / vui-timing-info / vui-hrd-info / slices=1 / no-opt-qp-pps / no-opt-ref-list-length-pps / no-multi-pass-opt-rps / scenecut-bias=0.05 / hist-threshold=0.03 / no-opt-cu-delta-qp / no-aq-motion / no-hdr10 / no-hdr10-opt / no-dhdr10-opt / no-idr-recovery-sei / analysis-reuse-level=0 / analysis-save-reuse-level=0 / analysis-load-reuse-level=0 / scale-factor=0 / refine-intra=0 / refine-inter=0 / refine-mv=1 / refine-ctu-distortion=0 / no-limit-sao / ctu-info=0 / no-lowpass-dct / refine-analysis-type=0 / copy-pic=1 / max-ausize-factor=1.0 / no-dynamic-refine / no-single-sei / no-hevc-aq / no-svt / no-field / qp-adaptation-range=1.00 / scenecut-aware-qp=0conformance-window-offsets / right=0 / bottom=0 / decoder-max-rate=0 / no-vbv-live-multi-pass 51c51 < Bit rate : 327 kb/s --- > Bit rate : 328 kb/s 58,59c58,59 < Stream size : 2.78 MiB (11%) < Source stream size : 2.78 MiB (11%) --- > Stream size : 2.79 MiB (11%) > Source stream size : 2.79 MiB (11%)
----------------------------
Terje J. H
well, considering predictability of bitrate this is good, but may be not very good for comparing max possible quality of encodings...
in ffmpeg/video/h265.mp4 profile I can see cin_quality=-1 setting. This setting absent from h264.mp4 profile.
Try to comment it out before rendering? May be we can/should create unconstrained (bitrate-wise) profiles for h265, too...
Just comment out # cin_quality=-1 in the profile window, doesn't seem to change anything: video wrench > Video Preset Compression: h265.mp4 Bitrate: 0 Pixels: yuv422p # cin_quality=-1 # use framerate for 1 keyframe/sec, needed for seeks keyint_min=30 x265-params=keyint=30 OK du -sh hd01_cin_rgb-float_ffmpeg_h265_yuv422p.mp4 26M hd01_cin_rgb-float_ffmpeg_h265_yuv422p.mp4 Terje J. H
Terje, I have not been following this thread very closely, but have a couple of comments.
A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons.
Your 2 different workstations have 2 different $HOME/.bcast5 so you must have set one to "S.U.V" and the other to "unflat" in Settings->Preferences, Appearance tab, theme selection in top left hand corner. @"Manual"
I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively?
Andrea, do you want to add this or should I try?
@"Manual" I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively?
Andrea, do you want to add this or should I try?
Good idea! The formats and codecs are too many and with too many variables; an idea could be to collect the ones used by the users; so we could indicate the combinations surely functional and tested. What do you say folks, would you like to send the formats and options you use? PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.
Den 06.11.2021 22:19, skrev Andrea paz via Cin:
@"Manual" I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively? Andrea, do you want to add this or should I try? Good idea! The formats and codecs are too many and with too many variables; an idea could be to collect the ones used by the users; so we could indicate the combinations surely functional and tested. What do you say folks, would you like to send the formats and options you use? PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.
Tip: Pick and compile a list of the most relevant and compatible (standard) file formats/options for Cin-GG/ffmpeg rendering. While I have just used the generic .mp4 container for my test files, Blu-ray and Ultra HD Blu-ray and DVD video discs use other. Some reference articles: https://blog.filestack.com/thoughts-and-knowledge/complete-list-audio-video-... https://www.computer.org/publications/tech-news/trends/8-best-video-file-for... https://www.borrowlenses.com/blog/video-file-formats/ https://www.adobe.com/creativecloud/video/discover/best-video-format.html https://support.google.com/youtube/troubleshooter/2888402?hl=en https://en.wikipedia.org/wiki/Video_file_format ------------ Terje J. H
Den 06.11.2021 23:20, skrev Terje J. Hanssen:
Den 06.11.2021 22:19, skrev Andrea paz via Cin:
@"Manual" I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively? Andrea, do you want to add this or should I try? Good idea! The formats and codecs are too many and with too many variables; an idea could be to collect the ones used by the users; so we could indicate the combinations surely functional and tested. What do you say folks, would you like to send the formats and options you use? PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.
Tip: Pick and compile a list of the most relevant and compatible (standard) file formats/options for Cin-GG/ffmpeg rendering. While I have just used the generic .mp4 container for my test files, Blu-ray and Ultra HD Blu-ray and DVD video discs use other.
Some reference articles: https://blog.filestack.com/thoughts-and-knowledge/complete-list-audio-video-...
https://www.computer.org/publications/tech-news/trends/8-best-video-file-for...
https://www.borrowlenses.com/blog/video-file-formats/ https://www.adobe.com/creativecloud/video/discover/best-video-format.html https://support.google.com/youtube/troubleshooter/2888402?hl=en https://en.wikipedia.org/wiki/Video_file_format ------------
IMO users often want encoding settings that fit the input file (source) quality and easy adjustments for the purpose of the output file. If Cin-GG/ffmpeg automatic could setup default format and render options/parameters/preset this way, it would be a good starting point. Maybe Cin-gg already is not far away from something like this? Again, to use my source file as an example: ffprobe hd01.mov [...........] Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hd01.mov': Metadata: creation_time : 2016-02-23T23:49:21.000000Z Duration: 00:01:11.24, start: 0.000000, bitrate: 200607 kb/s Stream #0:0(eng): Video: prores (HQ) (apch / 0x68637061), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn, 2500 tbc (default) Metadata: creation_time : 2016-02-23T23:49:21.000000Z handler_name : Apple Video Media Handler vendor_id : appl encoder : Apple ProRes 422 (HQ) Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16 channels, s32 (24 bit), 18432 kb/s (default) Metadata: creation_time : 2016-02-23T23:49:21.000000Z handler_name : Apple Sound Media Handler vendor_id : [0][0][0][0] As this source file is a 10-bit 422 video with pcm audio, I think the following render setup could fit automatic: Setting Format: rgb(a)-float color model Render File Format: FFMPEG mp4 Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4 Pixels : yuv422p10le Bitrate: ? Quality: ? Preset: Medium default w/i.e user purpose adjustment faster/slower Audio: would it be possible and compliant to have the option to just copy the source PCM audio? (Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?) --------------- Terje J. H
On Wednesday, November 10, 2021, Terje J. Hanssen via Cin < [email protected]> wrote:
Den 06.11.2021 23:20, skrev Terje J. Hanssen:
Den 06.11.2021 22:19, skrev Andrea paz via Cin:
@"Manual"
I think it could be useful if it is possible to add some overview table(s) i.e in the manual section FFmpeg Format Options inside CINELERRA-GG: That is, valid and Standard Profiles with Compression and Pixels properties for actual purposes and media, that works for Cin-GG and Cin-GG multibit respectively?
Andrea, do you want to add this or should I try?
Good idea! The formats and codecs are too many and with too many variables; an idea could be to collect the ones used by the users; so we could indicate the combinations surely functional and tested. What do you say folks, would you like to send the formats and options you use? PS (@Phyllis): In the meantime I attach you the modify proposed by Andrew.
Tip: Pick and compile a list of the most relevant and compatible (standard) file formats/options for Cin-GG/ffmpeg rendering. While I have just used the generic .mp4 container for my test files, Blu-ray and Ultra HD Blu-ray and DVD video discs use other.
Some reference articles: https://blog.filestack.com/thoughts-and-knowledge/complete- list-audio-video-file-formats/ https://www.computer.org/publications/tech-news/trends/8- best-video-file-formats-for-2020 https://www.borrowlenses.com/blog/video-file-formats/ https://www.adobe.com/creativecloud/video/discover/best-video-format.html https://support.google.com/youtube/troubleshooter/2888402?hl=en https://en.wikipedia.org/wiki/Video_file_format ------------
IMO users often want encoding settings that fit the input file (source) quality and easy adjustments for the purpose of the output file. If Cin-GG/ffmpeg automatic could setup default format and render options/parameters/preset this way, it would be a good starting point. Maybe Cin-gg already is not far away from something like this?
Again, to use my source file as an example:
ffprobe hd01.mov [...........] Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'hd01.mov': Metadata: creation_time : 2016-02-23T23:49:21.000000Z Duration: 00:01:11.24, start: 0.000000, bitrate: 200607 kb/s Stream #0:0(eng): Video: prores (HQ) (apch / 0x68637061), yuv422p10le(tv, bt709/unknown/unknown, top coded first (swapped)), 1920x1080, 182130 kb/s, SAR 1:1 DAR 16:9, 25 fps, 25 tbr, 2500 tbn, 2500 tbc (default) Metadata: creation_time : 2016-02-23T23:49:21.000000Z handler_name : Apple Video Media Handler vendor_id : appl encoder : Apple ProRes 422 (HQ) Stream #0:1(eng): Audio: pcm_s24le (lpcm / 0x6D63706C), 48000 Hz, 16 channels, s32 (24 bit), 18432 kb/s (default) Metadata: creation_time : 2016-02-23T23:49:21.000000Z handler_name : Apple Sound Media Handler vendor_id : [0][0][0][0]
As this source file is a 10-bit 422 video with pcm audio, I think the following render setup could fit automatic: Setting Format: rgb(a)-float color model Render File Format: FFMPEG mp4 Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4 Pixels : yuv422p10le Bitrate: ? Quality: ? Preset: Medium default w/i.e user purpose adjustment faster/slower Audio: would it be possible and compliant to have the option to just copy the source PCM audio?
well, I do not think cinelerra can just pass original audio untouched ( May be this can be coded, but IMO Cin's main focus was on re-processing input audio and video, not just cutting. Also, input sources for one session can vary... {this one is less of problem, just so far there is no 'guess' table that can be used for setting up parameters from already-known at encoding time session params}. Maybe encoding profiles can be used for this, need to look..
(Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?)
I was thinking about integrating tsMuxer but this does not solve problem about unavailability of pre-encoded packets in cin's vframe for mpeg2.. Probably BC_COMPRESSED type should be split for mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt from tablet ... May be for cuts-only you can export edl and then use ffmpeg's copy/mux mode ? (no ready to use script for this, sorry)
---------------
Terje J. H
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
Den 10.11.2021 00:39, skrev Andrew Randrianasulu:
On Wednesday, November 10, 2021, Terje J. Hanssen via Cin <[email protected] <mailto:[email protected]>> wrote:
As this source file is a 10-bit 422 video with pcm audio, I think the following render setup could fit automatic: Setting Format: rgb(a)-float color model Render File Format: FFMPEG mp4 Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4 Pixels : yuv422p10le Bitrate: ? Quality: ? Preset: Medium default w/i.e user purpose adjustment faster/slower Audio: would it be possible and compliant to have the option to just copy the source PCM audio?
well, I do not think cinelerra can just pass original audio untouched ( May be this can be coded, but IMO Cin's main focus was on re-processing input audio and video, not just cutting. Also, input sources for one session can vary... {this one is less of problem, just so far there is no 'guess' table that can be used for setting up parameters from already-known at encoding time session params}. Maybe encoding profiles can be used for this, need to look..
Possibly I thought merely on just "ffmpeg first input" and "ffmpeg output" (and Cin just as a gui front end). Regarding uncompressed PCM audio, FFMPEG looks to not support PCM in MP4; I read only Sony had a solution for that. --------- However I got FFMPEG to copy PCM when I transmuxed to MKV container at the same time as the video part was transcoded to x265: ffmpeg -i hd01.mov -c:a copy -c:v libx265 hd01_pcm_x265.mkv du -sh hd01.mov hd01_pcm_x265.mkv 1,7G hd01.mov 176M hd01_pcm_x265.mkv ---------- ffmpeg -i dv01.dv -c:a copy -c:v libx265 dv01_pcm_x265.mkv du -sh dv01.dv dv01_pcm_x265.mkv 2,0G dv01.dv 209M dv01_pcm_x265.mkv ------------------------
(Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?)
I was thinking about integrating tsMuxer but this does not solve problem about unavailability of pre-encoded packets in cin's vframe for mpeg2.. Probably BC_COMPRESSED type should be split for mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt from tablet ...
If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray for burning on BD-RE disk (and DVD-R), this could make it possible to preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) streams content on the same disc, as described in these papers: Blu-ray Disc, Rewritable Format, Audio Visual Application Format Specifications for BD-RE Version 2.1, March 2008: Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV directory http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Part3_V2.1_WhitePap... Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016. ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1. V2.0. BDMV. http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf Terje J. H
On Saturday, November 13, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 10.11.2021 00:39, skrev Andrew Randrianasulu:
On Wednesday, November 10, 2021, Terje J. Hanssen via Cin < [email protected] <mailto:[email protected]>> wrote:
As this source file is a 10-bit 422 video with pcm audio, I think the following render setup could fit automatic: Setting Format: rgb(a)-float color model Render File Format: FFMPEG mp4 Video compression: h264-10bit.mp4 user opti. h265-10bit.mp4 Pixels : yuv422p10le Bitrate: ? Quality: ? Preset: Medium default w/i.e user purpose adjustment faster/slower Audio: would it be possible and compliant to have the option to just copy the source PCM audio?
well, I do not think cinelerra can just pass original audio untouched ( May be this can be coded, but IMO Cin's main focus was on re-processing input audio and video, not just cutting. Also, input sources for one session can vary... {this one is less of problem, just so far there is no 'guess' table that can be used for setting up parameters from already-known at encoding time session params}. Maybe encoding profiles can be used for this, need to look..
Possibly I thought merely on just "ffmpeg first input" and "ffmpeg output" (and Cin just as a gui front end).
yeah... I posted link to python script supposedly (if I read desc. correctly!) cutting files according to edl. Now one might try it and assemble resulting clips by another ffmpeg command..
Regarding uncompressed PCM audio, FFMPEG looks to not support PCM in MP4; I read only Sony had a solution for that.
heh, it seems one can research this field for day and night)
---------
However I got FFMPEG to copy PCM when I transmuxed to MKV container at the same time as the video part was transcoded to x265:
good...
ffmpeg -i hd01.mov -c:a copy -c:v libx265 hd01_pcm_x265.mkv
du -sh hd01.mov hd01_pcm_x265.mkv 1,7G hd01.mov 176M hd01_pcm_x265.mkv ---------- ffmpeg -i dv01.dv -c:a copy -c:v libx265 dv01_pcm_x265.mkv
du -sh dv01.dv dv01_pcm_x265.mkv 2,0G dv01.dv 209M dv01_pcm_x265.mkv
------------------------
(Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?)
I was thinking about integrating tsMuxer but this does not solve problem about unavailability of pre-encoded packets in cin's vframe for mpeg2.. Probably BC_COMPRESSED type should be split for mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt from tablet ...
If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray for
burning on BD-RE disk (and DVD-R), this could make it possible to preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) streams content on the same disc, as described in these papers:
Blu-ray Disc, Rewritable Format, Audio Visual Application Format Specifications for BD-RE Version 2.1, March 2008: Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV directory http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Par t3_V2.1_WhitePaper_080406-15271.pdf
Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016. ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1. V2.0. BDMV. http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf
well, if you have player (or friend(s) with player(s)) you can try for yourself https://github.com/justdan96/tsMuxer/commits/master i think they have pre-compiled version. Be aware in tsmuxer context DV usually mean Dolby Vision, not dv as dv video codec.
Terje J. H
Den 13.11.2021 17:45, skrev Andrew Randrianasulu:
------------------------
(Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?)
I was thinking about integrating tsMuxer but this does not solve problem about unavailability of pre-encoded packets in cin's vframe for mpeg2.. Probably BC_COMPRESSED type should be split for mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt from tablet ...
If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray for burning on BD-RE disk (and DVD-R), this could make it possible to preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) streams content on the same disc, as described in these papers:
Blu-ray Disc, Rewritable Format, Audio Visual Application Format Specifications for BD-RE Version 2.1, March 2008: Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV directory http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Part3_V2.1_WhitePap... <http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Part3_V2.1_WhitePaper_080406-15271.pdf>
Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016. ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1. V2.0. BDMV. http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf <http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf>
well, if you have player (or friend(s) with player(s)) you can try for yourself
https://github.com/justdan96/tsMuxer/commits/master <https://github.com/justdan96/tsMuxer/commits/master>
i think they have pre-compiled version. Be aware in tsmuxer context DV usually mean Dolby Vision, not dv as dv video codec.
I downloaded and unpacked an appimage, but could not see BDAV mentioned. Have you seen any good user examples for tsMuxer? Terje J. H
On Saturday, November 13, 2021, Terje J. Hanssen <[email protected]> wrote:
Den 13.11.2021 17:45, skrev Andrew Randrianasulu:
------------------------
(Another one for "home-made HD videos" on Blu-ray discs (BDAV): Will it be possible to record (copy) source 1080iHDV.m2t files (video and audio) to the BD-R(E) discs?)
I was thinking about integrating tsMuxer but this does not solve problem about unavailability of pre-encoded packets in cin's vframe for mpeg2.. Probably BC_COMPRESSED type should be split for mjpeg/dv/mpeg2/h264 types but this is larger rework than I can attempt from tablet ...
If tsMuxer (or another dedicated utility) could author a BDAV Blu-Ray
for burning on BD-RE disk (and DVD-R), this could make it possible to preserve and test playabilty compliance of DV SD and MPEG-2 HD(V) streams content on the same disc, as described in these papers:
Blu-ray Disc, Rewritable Format, Audio Visual Application Format Specifications for BD-RE Version 2.1, March 2008: Figure 3.1.4.2.3: Stream file and Clip Information file for DV in BDAV directory http://www.blu-raydisc.com/Assets/Downloadablefile/BD-RE_Par t3_V2.1_WhitePaper_080406-15271.pdf
Blu-ray Disc Association. UDF2.5. 25/50GB. BDAV. As of December 2016. ROM4.0. Ultra HD Blu-ray™. ROM. Part3. V3.1. ROM. Part2. V2.0. ROM. Part1. V2.0. BDMV. http://www.blu-raydisc.info/docs/Spec_Info/AllBooksDecember2016.pdf
well, if you have player (or friend(s) with player(s)) you can try for yourself
https://github.com/justdan96/tsMuxer/commits/master
i think they have pre-compiled version. Be aware in tsmuxer context DV usually mean Dolby Vision, not dv as dv video codec.
I downloaded and unpacked an appimage, but could not see BDAV mentioned. Have you seen any good user examples for tsMuxer?
Terje J. H
if (qt5) gui works for you you can try following https://elatom.com/software/tsmuxergui-software-for-ts-muxing-with-mpeg-hevc... pure cmd line use a bit more involved from githab page --- Syntax The following lines form a list of tracks and their parameters. The format is as follows: <code name>, <file name>, <parameters>. Parameters are separated with commas, with each parameter consisting of a name and a value, separated with an equals sign. Example of META file: MUXOPT --blu-ray V_MPEG4/ISO/AVC, D:/media/test/stream.h264, fps=25 A_AC3, D:/media/test/stream.ac3, timeshift=-10000ms In this example one AC3 audio stream and one H264 video stream are multiplexed into BD disc. The input file name can reference an elementary stream or a track located inside a container. Supported input containers: TS/M2TS/MTS EVO/VOB/MPG/MPEG MKV MOV/MP4 MPLS (Blu-ray media play list file) Names of codecs in the meta file: Meta File Code Description V_MPEGI/ISO/VVC H.266/VVC V_MPEGH/ISO/HEVC H.265/HEVC V_MPEG4/ISO/AVC H.264/AVC V_MPEG4/ISO/MVC H.264/MVC V_MS/VFW/WVC1 VC1 V_MPEG-2 MPEG2 A_AC3 AC3/AC3+/TRUE-HD A_AAC AAC A_DTS DTS/DTS-Express/DTS-HD A_MP3 MPEG audio layer 1/2/3 A_LPCM raw pcm data or PCM WAV file S_HDMV/PGS Presentation graphic stream (BD subtitle format) S_TEXT/UTF8 SRT subtitle format. Encoding MUST be UTF-8/UTF-16/UTF-32 Each track may have additional parameters. Track parameters do not have dashes. If a parameter's value consists of several words, it must be enclosed in quotes. --- from old firum thread https://forum.doom9.org/archive/index.php/t-142559.html
Den 06.11.2021 19:47, skrev Phyllis Smith via Cin:
Terje, I have not been following this thread very closely, but have a couple of comments.
A minor visual notice, why differ the Render button geometries between my two workstations with the same, latest Cin-GG appimage installation? See the attached screenshot, the top Render window with square and round buttons vs the bottom Render window with romb buttons.
Your 2 different workstations have 2 different $HOME/.bcast5 so you must have set one to "S.U.V" and the other to "unflat" in Settings->Preferences, Appearance tab, theme selection in top left hand corner.
Phyllis, thanks that was correct, and I was not aware of this before I verified it. My second workstation (which previously was my office ws before I retired) has a really 2015 old .bcast and Cinelerra_rc with S.U.V theme set. Terje J. H
On Tuesday, November 2, 2021, Andrea paz via Cin <[email protected]> wrote:
CinX
Recently Andrew has worked on many patches to extend the encoding of CinGG; for example the "compile_multibit_X265.txt" patch. I guess compiling CinGG with this patch is equivalent to using CinGG-multibit.AppImage. I produced "test-multibit1.mp4" with the multibit appimage and I produced "test-multibit2.mp4" with CinGG compiled WITHOUT the patch. For both I used the preset: "h265-10bit.mp4". The results are the same: both files are encoded correctly at 10-bit. There is something I can't understand about the functioning of the patches I tried!
well, may be cin in both cases linked to system's libx265 (and this one was already compiled as multibit)? Can you check with ldd? --
Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
I wouldn't know where to use ldd; could you give me the exact command? I tried the following paths: $ cd /home/paz/cinelerra5/cinelerra-5.1/thirdparty/x265_3.5 $ ldd x265 linux-vdso.so.1 (0x00007ffc797f4000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6f51401000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f6f513f6000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f6f513ef000) libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007f6f513e1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6f511cb000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f6f51087000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007f6f51059000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f6f5103e000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f6f50e72000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6f519fd000) And: $ cd /lib $ ldd libx265.so linux-vdso.so.1 (0x00007ffd8bff7000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007faeb0b3b000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007faeb0b34000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007faeb091e000) libm.so.6 => /usr/lib/libm.so.6 (0x00007faeb07da000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007faeb07ae000) libc.so.6 => /usr/lib/libc.so.6 (0x00007faeb05e2000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007faeb1e1f000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007faeb05c5000) And then: $ ldd libx265.so.199 linux-vdso.so.1 (0x00007fffec574000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007feab9098000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007feab9091000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007feab8e7b000) libm.so.6 => /usr/lib/libm.so.6 (0x00007feab8d37000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007feab8d0b000) libc.so.6 => /usr/lib/libc.so.6 (0x00007feab8b3f000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007feaba37c000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007feab8b22000) I can't interpret the results or even if I found the right command.
On Tuesday, November 2, 2021, Andrea paz <[email protected]> wrote:
I wouldn't know where to use ldd; could you give me the exact command?
ldd path_to_cin? and see if it links with external libx265.. But I mostly hoped Phyllis will look into this.
I tried the following paths:
$ cd /home/paz/cinelerra5/cinelerra-5.1/thirdparty/x265_3.5 $ ldd x265 linux-vdso.so.1 (0x00007ffc797f4000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f6f51401000) librt.so.1 => /usr/lib/librt.so.1 (0x00007f6f513f6000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f6f513ef000) libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007f6f513e1000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f6f511cb000) libm.so.6 => /usr/lib/libm.so.6 (0x00007f6f51087000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007f6f51059000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f6f5103e000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f6f50e72000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f6f519fd000)
And: $ cd /lib $ ldd libx265.so linux-vdso.so.1 (0x00007ffd8bff7000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007faeb0b3b000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007faeb0b34000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007faeb091e000) libm.so.6 => /usr/lib/libm.so.6 (0x00007faeb07da000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007faeb07ae000) libc.so.6 => /usr/lib/libc.so.6 (0x00007faeb05e2000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007faeb1e1f000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007faeb05c5000)
And then: $ ldd libx265.so.199 linux-vdso.so.1 (0x00007fffec574000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007feab9098000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007feab9091000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007feab8e7b000) libm.so.6 => /usr/lib/libm.so.6 (0x00007feab8d37000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007feab8d0b000) libc.so.6 => /usr/lib/libc.so.6 (0x00007feab8b3f000) /usr/lib64/ld-linux-x86-64.so.2 (0x00007feaba37c000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007feab8b22000)
I can't interpret the results or even if I found the right command.
Doesn't seem to me. (I also attach the log of the CinGG build; I don't know if it will help) $ ldd cin linux-vdso.so.1 (0x00007ffc852d2000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007efe4197b000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007efe41966000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007efe41961000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007efe41958000) libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007efe41945000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007efe418f6000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007efe4182a000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007efe41801000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007efe417ca000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007efe417a9000) libz.so.1 => /usr/lib/libz.so.1 (0x00007efe4178f000) libvdpau.so.1 => /usr/lib/libvdpau.so.1 (0x00007efe4178a000) libva.so.2 => /usr/lib/libva.so.2 (0x00007efe4175b000) libva-x11.so.2 => /usr/lib/libva-x11.so.2 (0x00007efe41753000) libva-drm.so.2 => /usr/lib/libva-drm.so.2 (0x00007efe4174e000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007efe416c8000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007efe41672000) libXv.so.1 => /usr/lib/libXv.so.1 (0x00007efe4166a000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00007efe41650000) libasound.so.2 => /usr/lib/libasound.so.2 (0x00007efe41568000) libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x00007efe41561000) libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007efe4150c000) libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x00007efe414ee000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007efe414e7000) libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007efe414d7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007efe412c1000) libm.so.6 => /usr/lib/libm.so.6 (0x00007efe4117d000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007efe41151000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007efe41136000) libc.so.6 => /usr/lib/libc.so.6 (0x00007efe40f6a000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007efe40f3e000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007efe40f0e000) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007efe40e36000) libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007efe40e28000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007efe467ac000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007efe40e13000) libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007efe40d59000) libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007efe40d26000) libOpenGL.so.0 => /usr/lib/libOpenGL.so.0 (0x00007efe40cfa000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007efe40ced000) librt.so.1 => /usr/lib/librt.so.1 (0x00007efe40ce2000) libpulsecommon-15.0.so => /usr/lib/pulseaudio/libpulsecommon-15.0.so (0x00007efe40c57000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007efe40c02000) libudev.so.1 => /usr/lib/libudev.so.1 (0x00007efe40bd8000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007efe40bd3000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007efe40bcb000) libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007efe40ba4000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007efe40a6e000) libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007efe40a4b000) libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007efe409c9000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007efe40904000) libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007efe408fa000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007efe40883000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007efe407d8000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007efe40799000) libopus.so.0 => /usr/lib/libopus.so.0 (0x00007efe4073b000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007efe4070b000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00007efe40700000) libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007efe405f1000) liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007efe405ce000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007efe405c3000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007efe40487000) libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007efe4046b000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007efe40444000)
hm, yes, no libx265 in sight... so, hopefully your cin build uses statically-linked ffmpeg/x265... but then I have no idea why it works for you even without patches... anyway, working is better than non-working! I also have no idea why appimage (32 bit) fail for you.. may be deleting (!) some -dev packages on build server will force Cin to build and link to static libs (but if this works - then configure option for building everything as static as possible does not work as it should?) On Tuesday, November 2, 2021, Andrea paz <[email protected]> wrote:
Doesn't seem to me. (I also attach the log of the CinGG build; I don't know if it will help) $ ldd cin linux-vdso.so.1 (0x00007ffc852d2000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007efe4197b000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007efe41966000) libXinerama.so.1 => /usr/lib/libXinerama.so.1 (0x00007efe41961000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007efe41958000) libbz2.so.1.0 => /usr/lib/libbz2.so.1.0 (0x00007efe41945000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x00007efe418f6000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x00007efe4182a000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007efe41801000) libpng16.so.16 => /usr/lib/libpng16.so.16 (0x00007efe417ca000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007efe417a9000) libz.so.1 => /usr/lib/libz.so.1 (0x00007efe4178f000) libvdpau.so.1 => /usr/lib/libvdpau.so.1 (0x00007efe4178a000) libva.so.2 => /usr/lib/libva.so.2 (0x00007efe4175b000) libva-x11.so.2 => /usr/lib/libva-x11.so.2 (0x00007efe41753000) libva-drm.so.2 => /usr/lib/libva-drm.so.2 (0x00007efe4174e000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007efe416c8000) libGLU.so.1 => /usr/lib/libGLU.so.1 (0x00007efe41672000) libXv.so.1 => /usr/lib/libXv.so.1 (0x00007efe4166a000) libXft.so.2 => /usr/lib/libXft.so.2 (0x00007efe41650000) libasound.so.2 => /usr/lib/libasound.so.2 (0x00007efe41568000) libpulse-simple.so.0 => /usr/lib/libpulse-simple.so.0 (0x00007efe41561000) libpulse.so.0 => /usr/lib/libpulse.so.0 (0x00007efe4150c000) libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0x00007efe414ee000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007efe414e7000) libnuma.so.1 => /usr/lib/libnuma.so.1 (0x00007efe414d7000) libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007efe412c1000) libm.so.6 => /usr/lib/libm.so.6 (0x00007efe4117d000) libmvec.so.1 => /usr/lib/libmvec.so.1 (0x00007efe41151000) libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007efe41136000) libc.so.6 => /usr/lib/libc.so.6 (0x00007efe40f6a000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007efe40f3e000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007efe40f0e000) libharfbuzz.so.0 => /usr/lib/libharfbuzz.so.0 (0x00007efe40e36000) libbrotlidec.so.1 => /usr/lib/libbrotlidec.so.1 (0x00007efe40e28000) /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007efe467ac000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007efe40e13000) libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007efe40d59000) libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007efe40d26000) libOpenGL.so.0 => /usr/lib/libOpenGL.so.0 (0x00007efe40cfa000) libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007efe40ced000) librt.so.1 => /usr/lib/librt.so.1 (0x00007efe40ce2000) libpulsecommon-15.0.so => /usr/lib/pulseaudio/libpulsecommon-15.0.so (0x00007efe40c57000) libdbus-1.so.3 => /usr/lib/libdbus-1.so.3 (0x00007efe40c02000) libudev.so.1 => /usr/lib/libudev.so.1 (0x00007efe40bd8000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007efe40bd3000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007efe40bcb000) libgraphite2.so.3 => /usr/lib/libgraphite2.so.3 (0x00007efe40ba4000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x00007efe40a6e000) libbrotlicommon.so.1 => /usr/lib/libbrotlicommon.so.1 (0x00007efe40a4b000) libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007efe409c9000) libsystemd.so.0 => /usr/lib/libsystemd.so.0 (0x00007efe40904000) libasyncns.so.0 => /usr/lib/libasyncns.so.0 (0x00007efe408fa000) libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007efe40883000) libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007efe407d8000) libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007efe40799000) libopus.so.0 => /usr/lib/libopus.so.0 (0x00007efe4073b000) libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007efe4070b000) libogg.so.0 => /usr/lib/libogg.so.0 (0x00007efe40700000) libzstd.so.1 => /usr/lib/libzstd.so.1 (0x00007efe405f1000) liblz4.so.1 => /usr/lib/liblz4.so.1 (0x00007efe405ce000) libcap.so.2 => /usr/lib/libcap.so.2 (0x00007efe405c3000) libgcrypt.so.20 => /usr/lib/libgcrypt.so.20 (0x00007efe40487000) libresolv.so.2 => /usr/lib/libresolv.so.2 (0x00007efe4046b000) libgpg-error.so.0 => /usr/lib/libgpg-error.so.0 (0x00007efe40444000)
If you have built in that directory before, do a "make clean" before building. The build process might not detect all changes. MatN On Tue, 2 Nov 2021 18:53:13 +0300 Andrew Randrianasulu via Cin <[email protected]> wrote:
hm, yes, no libx265 in sight... so, hopefully your cin build uses statically-linked ffmpeg/x265... but then I have no idea why it works for you even without patches... anyway, working is better than non-working!
I also have no idea why appimage (32 bit) fail for you.. may be deleting (!) some -dev packages on build server will force Cin to build and link to static libs (but if this works - then configure option for building everything as static as possible does not work as it should?)
On Tuesday, November 2, 2021, Andrea paz via Cin <[email protected]> wrote:
All perfect installation and appimage. Thank you. Two questions: 1- I also tried to build OpenCV along with the source and had no errors. But the plugins don't appear in the plugins list. Instead putting manually the plugins in ".../bin/plugins" everything works normally. (PS: OpenCV has been updated recently, is it possible to create the most updated copies of the plugins?)
try to configure cin with opencv=sys, if you have latest installed? https://cinelerra-gg.org/download/CinelerraGG_Manual/How_Build_OpenCV_Plugin... (may be download location for opencv sources should be consistent with github releases urls? sourceforge tend to ban some locations... solvable via vpn, but meh)
2- I don't really understand the multibit version.Why put both the regular version and the multibit version? Are there things that work with one and not the other version?
PS2: The new DPX, mxf and Cineform formats are due more to Andrew than to me. -- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
participants (5)
-
Andrea paz -
Andrew Randrianasulu -
mnieuw＠zap.a2000.nl -
Phyllis Smith -
Terje J. Hanssen