<br><br>On Saturday, November 6, 2021, Terje J. Hanssen <<a href="mailto:terjejhanssen@gmail.com">terjejhanssen@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div>
    <br>
    <br>
    <div>Den 06.11.2021 17:15, skrev Andrew
      Randrianasulu:<br>
    </div>
    <blockquote type="cite">
      
      <br>
      <br>
      On Saturday, November 6, 2021, Terje J. Hanssen <<a href="mailto:terjejhanssen@gmail.com" target="_blank">terjejhanssen@gmail.com</a>>
      wrote:<br>
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
        <br>
        Den 06.11.2021 00:29, skrev Andrew Randrianasulu:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
          <br>
          <br>
          On Saturday, November 6, 2021, Terje J. Hanssen via Cin <<a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg.org</a>
          <mailto:<a href="mailto:cin@lists.cinelerra-gg.org" target="_blank">cin@lists.cinelerra-gg<wbr>.org</a>>>
          wrote:<br>
          <br>
          <br>
          <br>
              Den 05.11.2021 11:55, skrev Andrea paz:<br>
          <br>
                  @Terje<br>
                  If I understand correctly, you used only the h264.mp4
          and h265.mp4<br>
                  presets, changing the "Pixels" option from "420 8-bit"
          to "422<br>
                  10-bit"<br>
                  each time. Also, try using the 8, 10 and 12-bit h265
          presets;<br>
                  they are<br>
                  Andrew's new ones that work for me in the non-multibit
          version.<br>
                  I've tried non-multibit and I can render h264.mp4 at 8
          and<br>
                  10-bit and<br>
                  h265.mp4 at 8 and 10-bit. In short, in my case the
          non-multibit<br>
                  version always behaves as a sum of multibit and
          non-multibit.<br>
          <br>
          <br>
              @Andrea and All<br>
              I had a look into the Manual: Modifying FFmpeg Format
          Options<br>
              inside CINELERRA-GG<br>
              Figure 9.2: FFmpeg wrench, video preset, view and format
          options<br>
              <a href="https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html" target="_blank">https://cinelerra-gg.org/downl<wbr>oad/CinelerraGG_Manual/Modifyi<wbr>ng_FFmpeg_Format_Opt.html</a><br>
              <<a href="https://cinelerra-gg.org/download/CinelerraGG_Manual/Modifying_FFmpeg_Format_Opt.html" target="_blank">https://cinelerra-gg.org/down<wbr>load/CinelerraGG_Manual/Modify<wbr>ing_FFmpeg_Format_Opt.html</a>><br>
          <br>
              and tried to indicate cin version and parameters in my
          test file<br>
              names (no warranty the syntax is quite consistent), i.e<br>
          <br>
              hd01_cin_appimage_ffmpeg_h264_<wbr>yuv422p10le.mp4<br>
              File > Render | File format: FFMPEG mp4 | Video Wrench<br>
              > Video Preset | Compression: h264-10bit.mp4 | Pixels:
          yuv422p10le<br>
          <br>
              While this rendered OK on one of my workstation, another<br>
              installation wouldn't render at all with the following<br>
              Message log:<br>
              virtual void Render::handle close event(int):<br>
               Create new at labels checked, but no labels<br>
              (or other Failure)<br>
          <br>
          <br>
          <br>
          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....<br>
          <br>
          <br>
        </blockquote>
        <br>
        @Andrew<br>
        Thx, that's right - I don't know why or how the Render "Make new
        file box" was checked on my MSI workstation.<br>
        Unchecked it and the above file rendered ok.<br>
        <br>
        A minor visual notice, why differ the Render button geometries
        between my two workstations with the same, latest Cin-GG
        appimage installation?<br>
        See the attached screenshot,  the top Render window with square
        and round buttons vs the bottom Render window with romb buttons.</blockquote>
      <div><br>
      </div>
      <div>guess: because different Cin instances used different
        themes? </div>
      <div><br>
      </div>
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <br>
        One render option combination that Cin-gg regular reported error
        message (invalid or not supported), was as shown on the
        screenshot<br>
        h265-10bit.mp4 compression and yuv422p10le pixels<br>
        Is this correct?</blockquote>
      <div><br>
      </div>
      <div>well, it was motivation for me to write my patches, but
        apparently not all systems behave like this... </div>
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <br>
        <br>
        @Andrea<br>
        I succeeded to rendered further combinations and cleaned up my
        file name syntax as follows:<br>
        <br>
        du -sh hd01.mov hd01*app*.mp4<br>
        <br>
        1,7G    hd01.mov (input 10bit ProRes HQ file)<br>
        --------------------------<br>
        70M    hd01_cin_appimage_ffmpeg_h264-<wbr>10bit_yuv422p10le.mp4<br>
        72M    hd01_cin_appimage_ffmpeg_h264_<wbr>yuv420p.mp4<br>
        80M    hd01_cin_appimage_ffmpeg_h264_<wbr>yuv422p10le.mp4<br>
        82M    hd01_cin_appimage_ffmpeg_h264_<wbr>yuv422p.mp4<br>
        0    hd01_cin_appimage_ffmpeg_h265-<wbr>10bit_yuv422p10le.mp4
        (failed)<br>
        26M    hd01_cin_appimage_ffmpeg_h265-<wbr>10bit_yuv422p.mp4<br>
        26M    hd01_cin_appimage_ffmpeg_h265_<wbr>yuv422p.mp4<br>
        --------------------------<br>
        26M    hd01_cin-multi_appimage_ffmpeg<wbr>_h265-10bit_yuv422p10le.mp4<br>
        26M    hd01_cin-multi_appimage_ffmpeg<wbr>_h265-12bit_yuv422p12le.mp4<br>
        26M    hd01_cin-multi_appimage_ffmpeg<wbr>_h265_yuv422p10le.mp4<br>
        26M    hd01_cin-multi_appimage_ffmpeg<wbr>_h265_yuv422p.mp4</blockquote>
      <div><br>
      </div>
      <div>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? </div>
      <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
        <br>
        <br>
      </blockquote>
    </blockquote>
    <br>
    The file quality (sharpness) looks fine against the input hd01.mov
    file, the file colors varies a bit between greenish and
    yellow-brownish.<br>
    <br>
    I didn't change the default project setting, just loaded the
    hd01.mov file once, and rendered all files from it.<br>
    The default Setting > Format color model is RGBA-8bit<br>
    Obviously it should have been set to the higher RGB(A)-Float for
    this 10-bit 422 ProRes HQ file format?</div><div><br>
    <br>
    Terje J. H<br>
  </div></blockquote><div><br></div><div><br></div><div>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... </div>