HandBrake x265 pakkaus CPU VerySlow VS. GPU quality

[mRkukov]

Nyt kun vihdoin HandBrake sovelluksen nightly buildeista löytyy tuki AMD VCE (HW) encoodaukselle niin päätin testata että pärjääkö näyttiksellä pakattu video mitenkään CPU pakkaukselle. Tarkoitus on siis pakata vanhat x264 videot vuosien ja vuosien varrelta pienempään tilaan ilman suurempaa laatuhäviötä. CPU:lla tuo teratavun pakkaillu kestäisi pienen ikuisuuden myös 8-core prosessorilla, joten tarvitaan nopeampaa keinoa. GPU:lla sama onnistuu todella sutjakasti.

Lähdemateriaali on esimerkissä Canon SX1 kamerasta tulevaa 1080p h264 reilulla 21Mbps nopeudella. 24fps materiaali tuolla nopeudella on kohtalaisen tarkkaa myös nopeassa liikkeessä.

Valitsin testiin vesihiihtovideon, jossa kuvaan hiihtäjää mutkassa reilulla zoomilla niin että tausta heiluu ja vaihtuu nopealla tahdilla. Kuvassa myös paljon järveä, auringon heijastusta vedestä ja hiihtäjän/veneen jättämä vellova vesimassa. Kyseessä siis todella todella "raskas" skene pakkaukselle, koska auringossa heijastelevat vesipisarat ja vesimassan vellomiset on helppo pakata tasalaatuiseksi mössöksi. Samoin tummempi metsä taustalla. Silloin kuva ei kuitenkaan vastaisi enää lähellekään alkuperäistä. Tavoite olisi saada tiedostokoko noin puoleen ilman suurempia laatuhäviöitä.

Alkuperäinen: Canon SX1 h264 1080p ~21Mbps (302MB)

GPU kiihdytetyt asetukset:
VCE 5Mbps Quality 2-pass (109MB)
VCE 8Mbps Quality 2-pass (125MB)
VCE 10Mbps Quality 2-pass (141MB)



CPU asetukset:
CPU VerySlow 8Mbps 2-pass (113MB)


jatkuu seuraavassa viestissä...

 

[mRkukov]

...
Järjestys:

Original,
VCE 5Mbps,
VCE 8Mbps,
VCE 10Mbps,
CPU VerySlow 8Mbps







Päätelmät:
CPU pakkauksen "VerySlow" asetuksellakaan voi suoraan unohtaa. Pakkaus teki kuvan todella suttuiseksi ja kuvaan tuli myös "haamu" seuraavasta kuvasta. Tämä siis siitä huolimatta että fps oli "same as source". Pitää vielä testata sama suoraan ffmpeg kanssa, koska tuossa on nyt pakosti jotain häikkää. Joka tapauksessa CPU pakkaus on niin hidasta että se tippuu pois vaihtoehdoista riippumatta laadusta.

CPU pakkauksen kanssa videossa tuntui olevan enemmän p-frameja, jolloin haku oli huomattavasti nopeampaa. GPU pakatussa joutui soittamaan aina todella pitkään ennen kuin kuva palautui. Täytyy selvittää miten tuon saa korjattua, koska nyt haku on liian hidasta ja epätarkkaa.

GPU pakkauksen kanssa 5/8/10 Mbps nopeuksien laatuerot tuntuvat olevan aika pieniä. Kyllä isommalla bittinopeudella saa jonkin verran enemmän yksityiskohtia, mutta ei nyt ihan kauheasti. Toisaalta edes 10Mbps ei vastaa täysin alkuperäistä - "yllätys".

Mitä mieltä olette kuvanlaadusta? Mikä riittäisi teille? Onko ideoita miten haku/seeking saisi toimimaan paremmin ja miksi cpu pakattu oli mössöä (voin uusia testin)?

 

[Lagittaja]

Eihän sulla edes ole samat freimit tässä vertailussa ja asetuksista sen verran että x265:n kanssa tulee käyttää grain tunea, tämän virheen näyttää todella moni tekevän ja sitten heitetään informaatiota hukkaan. x265:ssä kun ei (vielä) ole x264 tapaan film tunea, grain tune on tällä hetkellä se vastaava jota pitäisi käyttää.
Ja lisäksi tuo veryslow preset nyt on aika naurettava valinta nopeuden kannalta, medium on vähän järkevämpi.
Ja niistä freimeistä vielä sen verran että jos haluat freimejä vertailla niin sitten enkoodaus pitää tehdä niin että vertaillaan saman tyyppisiä freimejä, sulla nyt näyttäisi tuossa olevan VCE tuloksista I-freimejä ja CPU tuloksista P tai B.
Video compression picture types - Wikipedia

Eli tässä nyt mentiin vähän perse edellä puuhun.

Edit: Ja missä on enkoodaus logit?

 

[mRkukov]

Eihän sulla edes ole samat freimit tässä vertailussa

Kyllä on:

Pakkaus teki kuvan todella suttuiseksi ja kuvaan tuli myös "haamu" seuraavasta kuvasta. Tämä siis siitä huolimatta että fps oli "same as source".

asetuksista sen verran että x265:n kanssa tulee käyttää grain tunea

Ja 99% handbraken käyttäjistä ei moista tiedä.

Ja lisäksi tuo veryslow preset nyt on aika naurettava valinta nopeuden kannalta, medium on vähän järkevämpi.

Tarkoitus olikin ns. "paras mahdollinen" laatu.

Ja niistä freimeistä vielä sen verran että jos haluat freimejä vertailla niin sitten enkoodaus pitää tehdä niin että vertaillaan saman tyyppisiä freimejä, sulla nyt näyttäisi tuossa olevan VCE tuloksista I-freimejä ja CPU tuloksista P tai B.

Eka vastaus. CPU pakatussa videossa melkein joka frame oli suttua verrattuna VCE pakattuun, vaikka framerate oli asetettu "same as source". Kerro toki mistä moinen johtuu, jos tiedät.

Eli tässä nyt mentiin vähän perse edellä puuhun.

Ei oikeastaan. Testi siitä miten peruskäyttäjä handbrakea käyttäisi... paitsi että käytin nightly buildia.

 

[Lagittaja]

Kyllä on:

(En tiedä toimiiko tuo kirahvi kun näpyttelen tätä puhelimesta mutta ei ole samaa freimiä nähnytkään kun tausta hyppii eestaas...)

Tarkoitus olikin ns. "paras mahdollinen" laatu.

Paitsi että se laatu on määritelty jo pääasiassa sillä bittivirralla, varsinkin kun H.265:lle annetaan näin paljon pelivaraa.

Aika helvetin suuri bittivirta siis FHD tavaralle.​

Presetti päättää kuinka monimutkaisia kikkoja ja kuinka montaa eri juttua enkooderi voi kokeilla enkoodauksessa ts. kuinka paljon aikaa siihen halutaan uhrata.
Tietenkin tämä vaikuttaa pakkaussuhteeseen eli kuinka hyvin bitit saadaan hyödynnettyä mutta tällä nyt ei tällaisilla bittivirroilla ole yhtään mitään merkitystä. Eri asia sitten kun vertaillaan 50-400Kbps aluetta jolloin näillä ekstra kikoilla saavutetaankin jotain.

Eli kuten sanoin, medium on järkevä. Se saavuttaa mahdollisimman hyvän laadun käyttämättä siihen helvetin paljon aikaa.

Eka vastaus. CPU pakatussa videossa melkein joka frame oli suttua verrattuna VCE pakattuun, vaikka framerate oli asetettu "same as source". Kerro toki mistä moinen johtuu, jos tiedät.

ja asetuksista sen verran että x265:n kanssa tulee käyttää grain tunea, tämän virheen näyttää todella moni tekevän ja sitten heitetään informaatiota hukkaan. x265:ssä kun ei (vielä) ole x264 tapaan film tunea, grain tune on tällä hetkellä se vastaava jota pitäisi käyttää.

Video compression picture types - Wikipedia

Kuten jo sanoin ja giffistä näkee, et vertaile samoja freimejä. X265 käyttää ison kasan P ja B freimejä koska se pystyy ja annoit sille valovuoden aikaa parantaa pakkaussuhdetta miettimällä niitä P ja B freimejä sinne mahdollisimman paljon ja tehdä niistä mahdollisimman kompressoituja.
Tietenkin jos pläräät freimi kerrallaan niin sutultahan se näyttää koska katsot freimi kerrallaan. Video on video.
Kuten jo sanoin, jos haluat vertailla freimejä keskenään (kahden enkooderin välillä) niin sinun tulee varmistaa että vertailet samoja freimejä eli I freimejä.
Dokumentointi kertoo mitä nuppeja pitää vääntää.

Ja 99% handbraken käyttäjistä ei moista tiedä.

https://x265.readthedocs.io
Ja mitä se Handbrake nyt tähän vaikuttaa, eikö testin pointti ollutkaan enkoodereiden vertailu?
Jos vertailet enkoodereita ja haluat esittää tuloksia ja vetää niistä johtopäätöksiä niin onko ihan kohtuutonta odottaa että sinä itse tutustuisit siihen mitä testaat?

Ei oikeastaan. Testi siitä miten peruskäyttäjä handbrakea käyttäisi... paitsi että käytin nightly buildia.

Eli tämä testisi ei ollutkaan x265 CPU vs H.265 VCE vaan tässä näytetään kuinka tulee huonoa jälkeä kun työkaluja ei käytetä oikein.

Summarum, perse edellä puuhun.

 

[mRkukov]

Kuten jo sanoin ja giffistä näkee, et vertaile samoja freimejä. X265 käyttää ison kasan P ja B freimejä koska se pystyy ja annoit sille valovuoden aikaa parantaa pakkaussuhdetta miettimällä niitä P ja B freimejä sinne mahdollisimman paljon ja tehdä niistä mahdollisimman kompressoituja.
Tietenkin jos pläräät freimi kerrallaan niin sutultahan se näyttää koska katsot freimi kerrallaan. Video on video.
Kuten jo sanoin, jos haluat vertailla freimejä keskenään (kahden enkooderin välillä) niin sinun tulee varmistaa että vertailet samoja freimejä eli I freimejä.
Dokumentointi kertoo mitä nuppeja pitää vääntää.

Kerro nyt ihmeessä että miten vertaan samaa framea jos cpu pakkauksella sitä ei ole olemassa? En tiedä miksi, mutta cpu pakatussa lähes kaikki oli suttua. Vce pakattu taas kaikki teräviä, kuten lähdemateriaalikin. Jostain syystä cpu pakkaus ei siis toiminut oikein.

Vastauksista päätellen taidan laittaa ketjun lukkoon kun ei kerran saa tehdä vertailua, joka on itselle ajankohtainen. Bittinopeus on kova, koska halusin mahdollisimman vähän häviötä. Eikö silloin saa käyttää h265 pakkausta vai mikä ihme se ongelma nyt oikein on?

Ja mitä se Handbrake nyt tähän vaikuttaa

Sitä että se on otsikossa ensimmäisenä ja tässä vertaillaan miten HANDBRAKELLA asiat hoituvat. Jos haluan vertailla puhtaasti encooderia itsessään niin ajan command linellä ffmpeg:tä.