FRAPS, encoding, YT - kako/sta?

[ilidan]

Napomenuo si da ne mozes da koristis Constant Quality (CRF) jer ti daje preveliki fajl. Ako povecas CRF dobices manji fajl. Recimo, CRF 24 daje oko 2x manji fajl od CRF 18.
Znaj i ovo - pri istoj izlaznoj velicini fajla i istim podesavanjima CRF i 2-pass mod daju isti vizuelni kvalitet.

 

[alfaunits]

Super - a ja pre toga da bajem u bob koji CRF da koristim da bi dobio prihvatljivu velicinu kad nemam predstavu koliko je na bilo kojem CRF (ako nisam taj video isprobao nikako kako bih znao)

Ovo Fast/Slow presets su Speed vs. Quality samo, jel' tako?

 

[weasel]

da , obrnuto proporcionalno

 

[alfaunits]

Imam video snimljen u 60fps i jedan snimljen u 30fps - maltene istih velicina. TF (FRAPS video, jos nije zavrsen encode 60fps videa)
140GB (60fps) vs 132GB (30fps)

Ono sto me buni je da MediaInfo kaze 440Mbps dok Details kaze 1.4Gbps.
Def. je ~440Mbps, tj. ~55MB/s. Tako da ako nekoga zanima koliko brz disk je potreban - pre ce CPU/GPU biti bottleneck

 

[ilidan]

Super - a ja pre toga da bajem u bob koji CRF da koristim da bi dobio prihvatljivu velicinu kad nemam predstavu koliko je na bilo kojem CRF (ako nisam taj video isprobao nikako kako bih znao)

Ovo Fast/Slow presets su Speed vs. Quality samo, jel' tako?

Zavisi od prioriteta. Ako ti je prioritet veličina fajla koristi 2-pass mod. A ako ti je prioritet kvalitet koristi CRF. Sa fiksnim bitrejtom ćeš uvek znati koliki će biti fajl ali nećeš znati kakav ćeš kvalitet dobiti na kraju. Sa CRF modom ćeš uvek znati kakav će biti kvalitet ali nećeš znati koliki će biti fajl.

Fast/Slow je Speet vs Quality kod 2-pass moda. Kod CRF moda ne mora nužno da bude.

 

[yooyo]

Hmm.. zar 2-pass mode ne daje bolji rezultat? Koliko ja kapiram 2-pass encoding, u prvom prolazu ze za zadani bitrate radi analiza svakog fejma i odredjuje se faktor kvalitta, kao i raspored I frejmova. Drugi prolaz je prava kompresija gde encoder koristi rezultate analize iz prvog prolaza.
Ovo je zgodno zato sto encoder moze da potrosi vise memorije za neki slozeni frejm i da smanji kolicinu memorije za neki jednostavan ili statican frame, a da pri tome postuje zadati bitrate. 2-pass encoding za neki zadani bitrate daje bolje rezultate od jednoprolazne kompresije za isti bitrate.
U jednoprolaznoj kompresiji, encoder nema pojma sta ga ceka, pa pakuje sve frejmove sa manje/vise istim kvalitetom.

 

[Wild Boy]

Nisam nesto poredio crf i avg ali u teoriji bi trebalo da je tako kako prica yooyo, zato ja uvek i koristim dva prolaza i avg.

 

[ilidan]

Bilo nekad, više nije tako.
@yooyo To o čemu ti pričaš se odnosi na 1-pass ABR vs 2-pass ABR. 1-pass ABR nema pojma kakva je kompleksnost filma pa sve pokušava da spakuje u gotovo identičan bitrejt dok 2-pass analizira film u prvom prolazu a zatim u drugom koristi te informacije da izvuče maksimalni kvalitet za svaki frejm.
CRF je nešto sasvim drugo i nema veze sa 1-pass ABR. Kada zadaš CRF vrednost ti ne zadaješ bitrejt već željeni kvalitet za data podešavanja. Enkoder ima slobodu da koristi bilo koji bitrejt da bi izvukao željeni kvalitet za svaki frejm. To na kraju rezultuje određenim prosečnim bitrejtom koji saznaješ tek kada se završi ceo proces.
Ako iskoristiš taj dobijeni bitrejt za 2-pass kompresiju dobićeš gotovo identičan kvalitet. Razlog za to je što i CRF i 2-pass mod kod x264 enkodera koriste istu logiku prilikom distribucije bitova. Možete to i ovako da shvatiš:
- kada zadaš CRF enkoder ima slobodu da sam odredi koji bitrejt mu je potreban za traženi kvalitet
- kada zadaš bitrejt enkoder pokušava da odredi koji CRF će dati traženi bitrejt.
CRF mod nije postojao pre H.264 enkodera, tj. x264 enkodera i ne može se porediti ni sa čim što su, i još uvek koriste Xvid, Divx, WMV i drugi enkoderi. Nekome će pasti na pamet CQ mod kod Xvid enkodera ali to ni isto. Ekvivalent CQ modu kod Xvid enkodera je QP mod kod x264 enkodera.
Kada je u pitanju CRF mod zaboravite sve što ste znali do sada o kompresiji i o 1-pass vs 2-pass modovima.
@Wild Boy .Ja sam poredio. Konkretno, uporedite SSIM za VerySlowCRF20 i VerySlow1387 u prvoj tabeli i VerySlowCRF20 i VerySlow359 u drugoj. Korišćena su ista podešavanja za CRF i 2-pass mod.
U oba slučaja poredio sam fajlove iste veličine. U prvom slučaju CRF20 mi je dao prosečan bitrejt 1387 koji sam iskoristio da 2-pass kompresiju. U drugom slučaju (drugi klip) CRF20 mi je dao bitrejt 359 koji sam opet iskoristio za 2-pass kompresiju.

 

[alfaunits]

Da li se promenila situacija sa Intel QS na IB-u, ili bolje receno sa softverom do sada pa da kvalitet outputa sa HD4000 parira kvalitetu sa CPU resenja?

 

[weasel]

Nije, niti ce ikad

 

[alfaunits]

Znaci to nije do softvera samo?? FP precision?

 

[weasel]

moze se reci da je samo do software-a... ali opet skoro pa ne moguce je napraviti software za tako nesto da valja.

 

[yooyo]

@ilidan:
Ako sam te razumeo Constant Quality mode prakticno osciluje sa bitrejtom pokusavajuci da odrzi kvalitet. Rezultat je stream nejednake "gustine" sto otezava seek u playerima. H264 stream je u stavi niz GOP struktura koje se sastoje od I, P i B frejmova. Bitrejt postavlja ogranicenje encoderu da 1 sekunndu materijala mora smestiti u odredjeni broj bitova. Decoder, na osnovu bitrejta i zadatog vremena veoma lako moze da utvrdi poziciju u fajlu u premota na zeljeno mesto. Ako bitrejt nije konstantan, onda je premotavanje prilicno kompleksno. Opet, na kraju zavisi kome sta treba.
Kada sam radio aplikaciju za selekciju cut-ova sa referentnih kamera koje snimaju mocap sesiju, referentne video snimke sam pakovao sa gustim I frejmovima, i u konstantnom bitrejtu. Aplikacija prikazuje do 15 video streamova istovremeno i ako video file nije spakovan na prvi nacin, premotavanje je nocna mora.

 

[Wild Boy]

Probao sam sada sa crf i istim bitrejtom na 2pass kompresiji i zaista je crf dao za dlaku bolju sliku i za nekih 30% brze obavio posao

 

[alfaunits]

To je super ali.... ako mi treba max. neka velicina fajla, ispada da, kao sto rekoh, treba da bajem u bob koji CRF treba da postavim da bi se to desilo

 

[weasel]

Pa ako ti treba target size naravno da ces ici na 2pass

 

[weasel]

@ilidan:
Ako sam te razumeo Constant Quality mode prakticno osciluje sa bitrejtom pokusavajuci da odrzi kvalitet. Rezultat je stream nejednake "gustine" sto otezava seek u playerima. H264 stream je u stavi niz GOP struktura koje se sastoje od I, P i B frejmova. Bitrejt postavlja ogranicenje encoderu da 1 sekunndu materijala mora smestiti u odredjeni broj bitova. Decoder, na osnovu bitrejta i zadatog vremena veoma lako moze da utvrdi poziciju u fajlu u premota na zeljeno mesto. Ako bitrejt nije konstantan, onda je premotavanje prilicno kompleksno. Opet, na kraju zavisi kome sta treba.
Kada sam radio aplikaciju za selekciju cut-ova sa referentnih kamera koje snimaju mocap sesiju, referentne video snimke sam pakovao sa gustim I frejmovima, i u konstantnom bitrejtu. Aplikacija prikazuje do 15 video streamova istovremeno i ako video file nije spakovan na prvi nacin, premotavanje je nocna mora.

Onda si efikasnost kompresije dosta smanjio zbog I frejmova
Sa danasnjim procesorima ako se pusta naranvo 1 vide stream a ne 15 istovremeno... nikakav problem nece biti velika udaljenost I frejmova jer je decoding time neprimetno mali sa brzinom danasnjih procesora

 

[alfaunits]

Ako video nema index i VBR je (kao sto je CRF output), seek ne zavisi samo od CPU-a vec i od diska, a dosta podataka se obradi i baci da bi se nasao pravi frame.
Ako ima index, zna gde najblize da uradi seek barem, i dosta je brzi. Ako nema, efektivno mora da procita od trenutne do zadate lokacije (ili od pocetka ako je zadata pre trenutne) sve frejmove.

Dobro poredjenje je Niz naspram Hash Table. Niz = CBR, VBR sa Indexom = Hash Table sa odlicnim kljucem, VBR bez Indexa = Hash Table sa najgorim mogucem kljucem (tj. key algoritmom)

 

[yooyo]

@weasel:
Jesam izgubio na kvalitetu, ali zato aplikacija ima dosta brzi odziv. Sve je tradeoff.

 

[ilidan]

@ilidan:
Ako sam te razumeo Constant Quality mode prakticno osciluje sa bitrejtom pokusavajuci da odrzi kvalitet. Rezultat je stream nejednake "gustine" sto otezava seek u playerima. H264 stream je u stavi niz GOP struktura koje se sastoje od I, P i B frejmova. Bitrejt postavlja ogranicenje encoderu da 1 sekunndu materijala mora smestiti u odredjeni broj bitova. Decoder, na osnovu bitrejta i zadatog vremena veoma lako moze da utvrdi poziciju u fajlu u premota na zeljeno mesto. Ako bitrejt nije konstantan, onda je premotavanje prilicno kompleksno. Opet, na kraju zavisi kome sta treba.
Kada sam radio aplikaciju za selekciju cut-ova sa referentnih kamera koje snimaju mocap sesiju, referentne video snimke sam pakovao sa gustim I frejmovima, i u konstantnom bitrejtu. Aplikacija prikazuje do 15 video streamova istovremeno i ako video file nije spakovan na prvi nacin, premotavanje je nocna mora.

Ako video nema index i VBR je (kao sto je CRF output), seek ne zavisi samo od CPU-a vec i od diska, a dosta podataka se obradi i baci da bi se nasao pravi frame.
Ako ima index, zna gde najblize da uradi seek barem, i dosta je brzi. Ako nema, efektivno mora da procita od trenutne do zadate lokacije (ili od pocetka ako je zadata pre trenutne) sve frejmove.

Dobro poredjenje je Niz naspram Hash Table. Niz = CBR, VBR sa Indexom = Hash Table sa odlicnim kljucem, VBR bez Indexa = Hash Table sa najgorim mogucem kljucem (tj. key algoritmom)

H.264 enkoderi a među njima i x264 enkoder uopšte nemaju CBR mod. Constant Quality osciluje bitrejt isto kao i 2-pass mod. I ABR mod osciluje bitrejt, samo u manjoj meri u odnosu na CRF i 2-pass. Mada, i to se može promeniti ako povećaš --ratetol sa 1 na neku veću vrednost. Recimo, --bitrate 2000 --ratetol 100 će ti dati apsolutni VBR s tim što konačan bitrejt uopšte neće biti 2000 već ko zna koliko.
Pretraga fajla ne zavisi od dekodera već od splitera. Koliki će brz odziv biti prilikom pretrage zavisi da li pretražuješ po key frejmovima ili ne. Indeks o key frejmovima ne sadrži elementarni video strim već kontejner u koji je video strim upakovan (AVI, MKV, MP4 itd.). Kako će svaki kontejner interno locirati indeks sa key frejmovima je stvar tog kontejnera. Recimo, AVI čuva indeks na kraju fajla. MP4 ga može čuvati i na početku i na kraju.
Ako ne pretražuješ po key frejmovima brzina odziva će zavisiti od jačine procesora i rastojanja između traženog frejma i prethodnog key frejma. Kao što znate, samo se key frejmovi (I frejmovi) mogu dekodirati nezavisno od ostalih dok P i B frejmovi zahtevaju da se pre njihovog dekodiranja dekodiraju i svi prethodni frejmovi od kojih oni zavise. Sa druge strane, pretraga po key frejmovima je trenutna. Ovo se podešava u plejeru ili spliteru. U MPC-HC ta opcija se nalazi u Options - Tweaks - Fast Seek (on keyframe).