Dotaz: do čeho renderovat

[marek_hb]

Ahoj,

udělal jsem si radost a teď kromě koupě SSD řeším ještě do čeho v linuxu renderovat - jsem ve videotvorbě hrubý amatér a rád bych se vyhnul zbytečným chybám

na stříhání používám kdenlive (a v podstatě nemám doma windows na použitelném počítači, tzn musím pod linuxem) a vyhovuje mi - jenže u videí ze staré kamery, nebo foťáku stačil mpeg4 a vyšší bitrate a bylo to celkem dobrý

u videí z téhle hračky mám pocit, že jakýkoli převod videa je znát

co by jste doporučili pro zachování maximální kvality? velikost souborů moc neřeším

---

---

Odpovědi

[Jendа]

x264 s velkým bitrate, podle mě to nemá konkurenci.

[elenril]

Maximální kvalita je lossless, takže libovolný bezztrátový kodek podle požadovaných vlastností (obskurnost, rychlost de/encodingu, komprese,....). x264 v bezztrátovém modu asi nebude úplně špatná volba.

avconv -codecs|grep '^.EV..S'
avconv version 9.4-6:9.4-1, Copyright (c) 2000-2013 the Libav developers
  built on Mar 24 2013 18:29:15 with gcc 4.7 (Debian 4.7.2-5)
Codecs:
 D..... = Decoding supported
 .E.... = Encoding supported
 ..V... = Video codec
 ..A... = Audio codec
 ..S... = Subtitle codec
 ...I.. = Intra frame-only codec
 ....L. = Lossy compression
 .....S = Lossless compression
 -------
.EVI.S ljpeg                Lossless JPEG
DEVILS jpegls               JPEG-LS
DEVI.S rawvideo             raw video
DEVI.S huffyuv              HuffYUV
DEV.LS h264                 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_vdpau ) (encoders: libx264 )
DEV..S ffv1                 FFmpeg video codec #1
DEVI.S zlib                 LCL (LossLess Codec Library) ZLIB
DEV..S qtrle                QuickTime Animation (RLE) video
DEV..S png                  PNG (Portable Network Graphics) image
DEVI.S ppm                  PPM (Portable PixelMap) image
DEVI.S pbm                  PBM (Portable BitMap) image
DEVI.S pgm                  PGM (Portable GrayMap) image
DEVI.S pgmyuv               PGMYUV (Portable GrayMap YUV) image
DEVI.S pam                  PAM (Portable AnyMap) image
DEVI.S ffvhuff              Huffyuv FFmpeg variant
DEVI.S bmp                  BMP (Windows and OS/2 bitmap)
DEV..S zmbv                 Zip Motion Blocks Video
DEV..S flashsv              Flash Screen Video v1
DEVILS jpeg2000             JPEG 2000 (decoders: libopenjpeg ) (encoders: libopenjpeg )
DEVI.S targa                Truevision Targa image
DEVI.S tiff                 TIFF image
DEV..S gif                  GIF (Graphics Interchange Format)
DEVI.S pcx                  PC Paintbrush PCX image
DEVI.S sunrast              Sun Rasterfile image
DEV.LS dirac                Dirac (decoders: libschroedinger ) (encoders: libschroedinger )
DEVI.S v210                 Uncompressed 4:2:2 10-bit
DEVI.S utvideo              Ut Video
DEVI.S v410                 Uncompressed 4:4:4 10-bit
DEVI.S xwd                  XWD (X Window Dump) image
.EVI.S xbm                  

Jestli chceš ztrátově, tak není o čem uvažovat -- použij x264.

Nebo pokud jsi hipster tak můžeš zkusit HEVC, případně VP9 podle politických preferencí, ale podpora není zatím nic moc.

[marek_hb]

dík za info - ještě dotaz - umí kdenlive při renderování spolupracovat s GPU? mám nvidii 8600 GT

na stránkách kdenlive je podpora spíš novějších karet (jestli jsem dobře hledal)

[Jendа]

Tak kdyby umělo, tak to asi bude OpenCL a bude podporovat všechny, ne? Akorát u horších karet se to nemusí vyplatit.

[elenril]

Nevím co všechno se u tebe skrývá pod pojmen "renderování", já se můžu vyjádřit jen ke kodování videa. Jestli kdenlive samo o sobě dělá něco na GPU nemám ponětí.

Nakolik vim, nejnovější verze x264 umějí používat OpenCL na lookahead, a snad se tím dosahuje i nějakého zrychlení. Ale od vývojářů jsem převážně slyšel tvrzení v tom smyslu, že GPU se na tyhle úkoly vůbec nehodí a nějak to pořádně využít je hrozně složité.

Jinak když se říká "encoding/decoding na GPU", tak se za tím skrývá speciální vyhrazený čip na grafické kartě, nedělá se to přes shadery. Takže tam se nedá moc mluvit o spolupráci -- ten čip je černá krabička na které člověk dělá bud všechno nebo nic. A co jsem slyšel, tak kvalita je u těchto hw hraček dost otřesná, x264 s presetem ultrafast to má překonávat jak kvalitou tak rychlostí.

[Jendа]

Nevím co všechno se u tebe skrývá pod pojmen "renderování"

Kdenlive (resp. MELT) typicky řeší stmívačky, přechody, vloženou grafiku, úpravy obrazu a další vylomeniny. Když je toho hodně a je to komplikované, nějaký výkon si to vezme.

A co jsem slyšel, tak kvalita je u těchto hw hraček dost otřesná, x264 s presetem ultrafast to má překonávat jak kvalitou tak rychlostí.

Stačí se podívat, co leze třeba z levných kamer, co „umí“ H.264 právě pomocí nějakého takového levného čipu.

[marek_hb]

jo, myslel jsem kodování videa - nevím proč mám zažité tomu říkat renderování

[jadd]

Asi proto, že v Kdenlive to kódování probíhá přes tlačítko které je přeloženo Renderovat. Nebo alespoň bývalo.

[Jendа]

V originále se to tlačítko jmenuje Render, takže bych nehledal chybu v překladu. Ono to hlavně skutečně dělá renderování (a pak to to vyrenderované kóduje, no).

[Ovocníček]

Ono "render" se občas používá pro ten krok, kdy se před enkódováním aplikují různé filtry na zdrojové video.

[Matlák]

Nevím jak kdenlive, ale cinelerra (a myslel jsem, že i různé jiné střižny) skutečně video tvoří až při "renderování" - tedy ten pojem je namístě. Pokud nevyrenderuju, veškerá moje dosavadní práce s videem je jen malinký XML soubor s indexy a obecně informacemi o tom jak to složit dohromady...

[Ovocníček]

To je logické - nekomprimované video by na disku zabíralo šílenýho místa.

[Ovocníček]

HEVC už je asi úplně finální (chybí mu nějaké razítko nebo tak, hehe), ale VP9 ještě ne (finalizace v červnu).

Jinak je VP9 zatím kurevsky pomalé, takže to chce počkat na optimalizace (a pak by člověk mohl čekat, až zlepší kvalitu, a pak...). Do HEVC bohužel momentálně taky můžete kódovat jen referenčním enkodérem (taky pomalé), takže taky nelze použít.

(Když říkám pomalé, tak tím myslím tak pomalé, že to fakt nejde použít - časy v minutách na jeden snímek...)

[Ovocníček]

Jinak H.264 skrz x264 umožňuje kódovat s barevným samplováním 4:4:4, což bych doporučil vyzkoušet, protože normálně video formáty používají subsampling (chroma má jen jeden vzorek na každý 2x2 blok lumy). U počítačového renderingu by to v některých případech mohlo být znát.

[Ovocníček]

Jo aha, tak jestli jsou to videa z kamery, a ne CG rendery, tak potom zůstat u klasikcého 4:2:0 (zkrátka YV12). Aspoň vám to půjde všude přehrát.

[marek_hb]

zatím jsem to renderoval přes H.264 s bitrate 25 000 do .avi a vypadá to opravdu asi nejlíp z toho co jsem zkoušel

[marek_hb]

samozřejmě kromě x264 v bezztrátovém režimu - jenže tam už mi nestíhá přehrávat počítač (E6600 + nVidia GT 8600)

[elenril]

Nepoužívej konstantní bitrate. Bitrate má prakticky u všech moderních kodeků dost volný vztah s kvalitou. Pokud nemáš nějaký zvláštní důvod to dělat jinak, je s x264 nejlepší používat CRF (constant rate factor) ratecontrol, který automaticky vybírá bitrate tak aby celé video mělo zhruba stejnou kvalitu. CRF parametr je číslo od 0 do 51, kde menší je lepší kvalita (a větší soubor), 0 je bezztrátově a někde kolem 16 to má být (pro většinu lidí) nerozlišitelné od originálu.

[Ovocníček]

Tak tak, konstantní bitrate doprzní náročné scény (v menším měřítku se to týká i klíčových snímků, které mají vždy vyšší nároky na bitrate než péčka a béčka*) a třeba pak zbytečně bude plýtvat jinde.

* Teda, není to krása, jak mají všechny ta české výrazy pro druhy framů v kontextu kinematografie dvojí smysl? :D

[marek_hb]

díky - tohle jsme nevěděl, ale v kdenlive tuhle volbu nemůžu najít

[Jendа]

Zkusil bych to MELTu vnutit ručně jako parametr při renderování (musíš si v Kdenlive zkopírovat profil, existující nejdou upravovat) - vyhodit věci o bitrate a dát tam crf=20.

[marek_hb]

f=mp4 hq=1 acodec=aac ab=%audiobitrate+'k' ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 crf=16 g=250 bf=3 b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=%passes

třeba takhle?

tohle je původní H.264 (ztrátový)

[marek_hb]

ne původní, ale upravený - pardon

[marek_hb]

tak tohle nefunguje - vyleze z toho jen zvuk bez videa

[elenril]

Vypadá to dost hrůzně, většina z toho nejspíš nebude v dnešní době potřeba. Jestli máš libav nebo ffmpeg který není přes 2 roky starý, tak by to mělo stačit ořezat na f=mp4 hq=1 acodec=aac ab=%audiobitrate+'k' ar=48000 pix_fmt=yuv420p vcodec=libx264 crf=16 aspect=%dar pass=%passes

[marek_hb]

tak bohužel to nefunguje - obojí vytvoří jen zvuk - bez videa