<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Den 09.07.2024 01:43, skrev Andrew Randrianasulu:<br>
    > ........<br>
    ><br>
    > well, it was working in the past with configure switches
    enabling x264/x265 multibit versions compilation. Now x264 should be
    always multibit and x265 patched manually ... I'll think about
    something but not sure if there easy way to get this info, esp. for
    external ffmpeg.<br>
    ><br>
    > So far simplest way to test seems to be just trying to render
    10-bit x265 and see if it works ...<br>
    ><br>
    <br>
    Does this mean that the "regular" or basic CinGG version has
    multibit capability for all encoding (x264 included), except for
    x265 which has only 8-bit here?<br>
    And on the other hand, CinGG-Multibit has multibit capability for
    all encoding (x265 included), except for x264 which has only 8-bit
    here?<br>
     <br>
    Does this also mean that it is not possible to make a "smart",
    common CinGG version that has multibit capability for all encoding,
    x264 and x265 included?<br>
    <br>
    <br>
    <div class="moz-cite-prefix">Den 16.07.2024 09:24, skrev Andrew
      Randrianasulu via Cin:<br>
    </div>
    <blockquote type="cite"
cite="mid:CA+rFky7VtYDqrFB2ibrTyvRSFRHrgcgwsCJxJoMLTjdBeNovsA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="auto">
        <div><br>
          <br>
          <div class="gmail_quote">
            <div dir="ltr" class="gmail_attr">вт, 16 июл. 2024 г., 10:20
              Andrea paz via Cin <<a
                href="mailto:cin@lists.cinelerra-gg.org"
                moz-do-not-send="true" class="moz-txt-link-freetext">cin@lists.cinelerra-gg.org</a>>:<br>
            </div>
            <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let's
              wait before changing the name. There is a risk that
              playback on<br>
              the timeline (which is already problematic in CinGG) will
              be less<br>
              efficient. </blockquote>
          </div>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">As far as I understand x265 is *encoder* so
          playback performance should stay roughly the same ....</div>
        <div dir="auto"><br>
        </div>
        <div dir="auto"><br>
        </div>
        <div dir="auto">
          <div class="gmail_quote">
            <blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Let
              me do some more testing and even better would be to do<br>
              some more with less performing hardware (which I don't
              have). The<br>
              confusion involved with the name change could also be
              problematic. I'd<br>
              love the opinions of other users as well.<br>
              -- <br>
            </blockquote>
          </div>
        </div>
      </div>
      <br>
    </blockquote>
    <br>
    I wonder why I didn't get the following encoding formats to work<br>
    <blockquote type="cite"><br>
      <font face="Courier New, Courier, monospace">0   
        av1_svt_yuv420p_cfhd01.webm</font><br>
      <font face="Courier New, Courier, monospace">0   
        av1_vaapi_yuv420p_cfhd01.webm</font><br>
      <font face="Courier New, Courier, monospace">0   
        av1_yuv422p10le_cfhd01.webm</font></blockquote>
    <br>
    And won't it be possible to enable Intel qsv etc. hwaccel support
    with CinGG's "internal ffmpeg", when it is available for my system
    ffmpeg?  <br>
    <br>
    <br>
    <br>
    <br>
    <br>
  </body>
</html>