[Cin] Updated CinGG release for downloading the AppImage

[Terje J. Hanssen]

Den 06.11.2021 17:15, skrev Andrew Randrianasulu:
>
>
> On Saturday, November 6, 2021, Terje J. Hanssen 
> <terjejhanssen at gmail.com <mailto:terjejhanssen at gmail.com>> wrote:
>
>
>
>     Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
>
>
>
>         On Saturday, November 6, 2021, Terje J. Hanssen via Cin
>         <cin at lists.cinelerra-gg.org
>         <mailto:cin at lists.cinelerra-gg.org>
>         <mailto:cin at lists.cinelerra-gg.org
>         <mailto:cin at lists.cinelerra-gg.org>>> 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_Opt.html
>         <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html>
>            
>         <https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html
>         <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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20211106/7d4e17d6/attachment-0001.htm>