On Saturday, November 6, 2021, Terje J. Hanssen <terjejhanssen@gmail.com>
wrote:
Den 06.11.2021 00:29, skrev Andrew Randrianasulu:
On Saturday, November 6, 2021, Terje J. Hanssen via Cin <cin@lists.cinelerra-gg.org
<mailto:cin@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>
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?