Új hozzászólás Aktív témák

• #16015 #68216320 törölt tag #68216320 #16014

  Új Válasz 2021-10-13 00:56:39 #16015

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  #68216320

  törölt tag

  válasz #68216320 #16014 üzenetére

  Teasüti:
  Közben újra átolvasva a hozzászólásod felmerült bennem, hogy nem ugyanarról a felhasználásról beszélünk. Te a streaming-et említed, ahol ugye más szempontok elsődlegesek, én pedig az offline konténerizált video-ról beszéltem, ahol megint más.
  Stream esetén simán megfelel egy nvenc x minőség magasabb bitráta mellett alacsony latency-vel, míg egy tárolt, non-stream esetében szempont a kis méret és a megfelelő minőség is. Itt már jobban teljesít ugye a cpu. (Azt hiszem a cuda3.0 előtti időkben volt tisztán cuda az encoding, most valami részben más megoldás van már, van szerepe most is a cuda magnak, de van valami spéci fix hw is benne)
  Mindegy, a lényeg amit el szerettem volna mondani, hogy ezekkel a kódolásokkal a kulcsframe-ek miatt nem lineáris a skálázódás a thread-ek számának növekedésével.
  Leegyszerűsítve: Az encoding elmélet szerint vagy be kell várni a sok thread-et a keyframe-hez (sebesség csökkenés), vagy több keyframe-et kell csinálni (méret növekedés cq esetén, minőségromlás cb esetén). A vicc, hogy igazából mindkettő megtörténik.
  Ez nem sw és hw függő, hanem az algoritmus ilyen. Az x265 valamennyire jobb már ebben.
  Ha teheted próbálj ki egy 24+ thread feletti cpu encoding-ot és meglátod miről beszélek.

  De kicsit off lett a dolog, bár annyiban nem, hogy magam sem tudtam erről, amíg nem futottam bele az 5900x-el encoding közben abba, hogy nem gyorsult a várt módon a folyamat. Akkor kezdtem utánaolvasni a dolognak, hogy sok thread esetén miért lazsál láthatóan a cpu.

  [ Szerkesztve ]

Új hozzászólás Aktív témák