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...
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
