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

• #11194 #54625216 törölt tag MrChris #11190

  Új Válasz 2018-10-28 10:16:05 #11194

  Ú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

  

  #54625216

  törölt tag

  válasz MrChris #11190 üzenetére

  "Látom nem akarod megérteni, hogy a prores nem lossless, kb 30-40szeres tömörítés a valódi losslesshez képest."

  Szerintem Te nem akarod megérteni - annak ellenére, hogy feljebb már elmagyaráztam -, hogy a lossless, mint szakkifejezés nem a tökéletesen veszteségmentes tömörítést jelenti (mégha tükörfordításban ez is lenne a logikus), hanem a professzionális célra fejlesztett kodekek általános gyűjtőneve. Nem én találtam ki, egyszerűen ez ragadt meg a közbeszédben (amire nyilván az Apple és az Avid marketing teamje is rásegített egy kicsit).

  "Hiába a magasabb kategóriák prorese és dnxhdja ha a kameráink avchdját átkódoltatod abba azzal csak veszítesz."

  Abban egyetértünk, hogy önmagában az átkódolás semmilyen minőség javulással nem jár, hiszen információt nem tud a képhez adni, viszont veszteségről nincs értelme beszélni, mert még ha matematikailag le is vezethető az információ vesztés, az olyan szinten elhanyagolható, hogy felesleges foglalkozni vele, nem csak vizuálisan, de matematikai szinten sem. (Természetesen nem a proxy formátumokra értendő.)

  "puszta feltételezés, hogy az editor majd jól elrontja az avchd-t"

  Editora válogatja. Ez első sorban azon múlik, hogy az editor h264 decodere milyen, az editor belső renderengine-je milyen, miben cacheli a már lerenderelt szakaszokat, stb. A legfőbb gond ezzel, hogy az mpeg2, h264, h265 szabványok a bitráták és kódolási eljárások olyan széles spektrumát engedélyezik, hogy nem lehet kijelenteni, hogy adott h264 decoder úgy jó ahogy van anélkül, hogy tudnád, hogy milyen kódolású h264 az input.

  Ezen kívül azon is múlik, hogy mi a cél.
  Ezt is kifejtettem már feljebb, hogy ha a végeredmény az ügyfél számára elfogadható és a natív h264 editálás gyorsabb workflow-t eredményez, akkor nyilvánvalóan azt kell alkalmazni.
  Értsd: ha esküvői vagy családi videókat készítesz és kiismerted, hogy a kamera natív formátuma hogyan viselkedik a vágóprogramban és van egy jól bejáratott workflowd, akkor természetesen nincs a h264 editálással semmi gond.

  Ha viszont a cél mondjuk broadcast szabványnak megfelelő kódolású master és naponta rutinszerűen kell leadni több tíz percnyi hasznos anyagot úgy, hogy egyszerre akár 5-6 vágó is dolgozik párhuzamosan, miközben gyorsan átküldhető preview-kat is kell gyártani kb. ugyanekkora nagyságrendben, mindezt szigorú minőségi követelmények mellett, akkor a workflow-ba nem fér bele, hogy majd a vágóprogram megbírkózik valahogy a h264 kódolással.
  Amúgy pont ezért nem h264 vagy h265 encoder van a profi kamerákban illetve a hdmi recorderekben, hanem prores és dnxhd, mert azzal a produkció megspórolja az átkonvertálást, am az ő szintjükön fel se merül, hogy ne kellene elvégezni.

  "És azt viszont szintén csak feltételezed hogy ami előtömörítést és konvertálást alkalmaztál az a legjobban fekvő verziója az editornak."

  Megint csak editora válogatja. Általánosságban csak annyit lehet kijelenteni, hogy minden editorban a saját natív kodekjével érdemes dolgozni. Ez az FPC-nél a ProRes, az avidnál a DNxHD.
  A Premiere ebből a szempontból speciális darab, mivel a natív quicktime library-ra és a video for windows library-ra gányoltak rá egy engine-t, ami vagy működik, vagy nem.

  Gyakorlati példa:
  A jelenlegi munkahelyemen, ahol 3d animációs tv sorozatot gyártunk pl. egyszerre több igénynek is meg kell felelni: a jeleneteket dpx szekvenciákba renderelik a kompozitorok, azokból kell automatikusan proxy-t generálni vágáshoz, majd a végén tömörítetlen 4:2:2 10 bites mastert kell renderelni (ezt archiválja az ügyfél), amiből készül egy h264 preview és egy prores 4:2:2 HQ quicktime, ami adásba megy.
  Költségvetési okokból a Premiere mellett döntöttek (érts: vágók leadje azt ismerte a legjobban).
  Először mi is a legegyszerűbb megoldással próbálkoztunk: proxynak h264 mov ffmpeg-ből konvertálva.(Az Adobe Media Encodert nem tudtuk használni, mert a proxy generálásnak linuxos renderfarmon kellett futnia.)
  Na a Premiere kb. 10 percenként becrashelt, valószínűleg mert az ffmpeg által generált quicktime és az apple féle quicktime library összeakadt egymással. Ezután váltottunk sima photo-jpegre, eredmény ugyanaz. Megpróbáltunk mjpeg alapú avi-ra váltani, de kiderült, hogy avihoz nincs natív mjpeg kodek csak licenszelhető horror áron, ami nem kompatibilis semmivel. Így végül a megoldás utvideo kódolású avi lett, azzal teljesen ki tudtuk zárni a quicktime library-t, ráadásul a kodek létezik pc-re és mac-re is és az ffmpeg is ismeri.

  Ezt csak azért írom le, hogy lásd: ahány igény, annyi megoldás. Ezért nagyon óvatosan kell bánni az általános megfogalmazásokkal, hogy a h264 ugyanolyan, mintha lossless kodeket használnál, mert nem az. Lehet, hogy jó lesz, lehet hogy a céljaidnak megfelel, de az is lehet, hogy oltári szopás lesz belőle.

  "Annyi pluszt jelenthetne az eljárásod, hogy kevésbé terheli a cpu-t, gpu-t a kitömörítés, de ez ma már nem probléma."

  A beszélgetés ugyebár onnan indult, hogy Narumon panaszkodott a h265 magas erőforrásigényére és hogy emiatt inkább lemond a jobb minőségű kódolásról. Erre mondtam megoldásként, hogy a bevett gyakorlat vágóknál a vágóprogram natív "lossless" kodekjének a használata.

  Amúgy az erőforrásigény is relatív. Pl. több kamerás vágással, amikor a vágóprogramnak 5-6 videósávot kell egyszerre lejátszania még a legerősebb PC-t is meg lehet fingatni, ha mindegyik nyersanyag 200mbit sávszélességű 4K h265.

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