Handbrake ja rautaencode

[JiiPee]

Handbrake on tukenut vuosia Intelin quicksync rauta encoodausta, mutta nyt jos asentaa beta version eli nightly buildin, niin rauta encoodauksesta pääsee nautiskelemaan myös AMD:n näytönohjainta hyödyntäen.

Tuossa pikaisesti testaillut, niin kyllähän tuo aika kivasti vääntää Vega 56:n kanssa. Niin mukavasti että tää 4670K on tukkona ettei kaikkea tehoa saa Vegasta otettua ulos.

1080p matsua kun vääntää h265 muotoon niin jossain 140FPS:ssä pyörii ja Vegan kuormitus on Jossain 60% hujakoilla. CPU kaikki 4 corea 100%.

Testailkaas millasia lukemia saatte jos kiinnostaa.

Täällä myös jotain pikaisia testien tuloksia
Adding support for AMD Hardware encoding · Issue #697 · HandBrake/HandBrake

 

[zepi]

Mutta mikä on luopputuotteen laatu suhteessa siihen cpu-enkoodaukseen?

 

[JiiPee]

Mutta mikä on luopputuotteen laatu suhteessa siihen cpu-enkoodaukseen?

Se johtuu varmaan aika pitkälti katsojasta. Itse en esim. 42" full HD plasma ruudulla huomannut mitään eroa käyttikö quicksync vai vetikö CPU:lla kun oli about sama bitrate käytössä.
Toisten mielestä taas quicksync tekee täysin katselukelvotonta jälkeä.

 

[Elvis Jagger]

Eikö ero nyt tule siitä, että mitkä asetukset ja codecin ominaisuudet on käytössä. Eli sekä GPU- että CPU-enkoodauksella saa yhtä huonoa tai hyvää, mutta ero on se kauanko siihen menee.

 

[Pertti Kosunen]

Eli sekä GPU- että CPU-enkoodauksella saa yhtä huonoa tai hyvää, mutta ero on se kauanko siihen menee.

Yleensä rauta-pakkaus ei ole päässyt yhtä hyvään laatuun kuin x264/x265 jotka kykenevät jopa parempaan jälkeen kuin kaupalliset kilpailijat.

 

[Lagittaja]

Ei se rautapakkaus (QuickSync, Nvidia/AMD GPU enkooderit) ikinä pääse samalle tasolle laadussa kuin CPU:lla pyöritettävä x264/x265.
Toki jos heität tarpeeksi bittejä ongelmaa kohti niin häviäähän ne ongelmat aika hyvin ja näyttää ihan hyvältä mutta sen vastaavan laadun sitten tietenkin saa (huomattavasti) pienemmällä bittivirralla kun käyttää x264/x265.

Mutta ei siinä, jos omaan silmään näyttää tarpeeksi hyvältä niin good for you! Itse sen eron huomaan ja kyllähän se vituttaa kun joutuu käyttämään enemmän tehoa enkoodaukseen.

Nimimerkillä Stargate SG-1 DVD kokoelman transkoodaus kera NLmeans kohinanpoistot jne, voin kertoa että tähän meni kauan aikaa. Lopullinen pakkaussuhde vajaa 52% ja 55" ruudulta läheltä ihmeteltynä laatu miellyttää eikä eroa alkuperäiseen oikeastaan huomannut, pl. tietenkin ylimääräisen kohinan poissaolo.
Aikaa ensinnäkin meni asetusten hienosäätämiseen, (useisiin) testi enkoodauksiin ja vertailuihin, kohinanpoiston asetusten testaamiseen ettei poisteta liikaa informaatiota jne.
Tämä kun on arkistointi hommaa niin en todellakaan halua tehdä tätä uudelleen..

Joku toki voisi sanoa että arkistoinnissa alkuperäinen olisi paras mutta ei minulla niin paljon ole kiintolevytilaa..​

Jos olisin käyttänyt rautaenkoodausta ja jos pakkaussuhde olisi sama vajaa 52% niin ei siinä kyllä tulisi muutakuin paha mieli katsellessa.

 

[Elvis Jagger]

Yleensä rauta-pakkaus ei ole päässyt yhtä hyvään laatuun kuin x264/x265 jotka kykenevät jopa parempaan jälkeen kuin kaupalliset kilpailijat.

En tosiaan tainnut tajuta. Tämä siis onkin joku oma implementaatio kun luulin että se vaan joku rajapinta jolla ajetaan sitä samaa codecia.

 

[Pertti Kosunen]

Joku toki voisi sanoa että arkistoinnissa alkuperäinen olisi paras mutta ei minulla niin paljon ole kiintolevytilaa..

Levytila on nykyään halpaa, ripatulle datalle joka on helpohkosti lueattavissa uudelleen optisilta kiekoilta ei kannata rakentaa liian hienoja tallennusvälineitä (ECC/ZFS jne.).

 

[Lagittaja]

En tosiaan tainnut tajuta. Tämä siis onkin joku oma implementaatio kun luulin että se vaan joku rajapinta jolla ajetaan sitä samaa codecia.

Jep. H.264 tai H.265 on vain video pakkaus standardi josta sitten on olemassa useita eri implementaatioita.

 

[Diizzel]

Osaakohan kukaan sanoa, mistä syystä tämä vce:llä pakattu h265 tuntuu olevan raskaampaa pyörittää kuin x265:lla pakattu? Nassille olen blurayta rippaillu, jonkin verran ja niin apple tv, kuin tietokonekkin osaavat tuota x265-materiaalia skippailla luontevasti sekunnin tai parin viiveillä ympäri elokuvaa, mutta näyttiksellä pakattu matsku tuntuu vievän kymmenestä kahteenkymmeneen sekuntia, jos hyppää elokuvasta yhtään pidemmän matkan eteenpäin.

 

[Pertti Kosunen]

Missä kääreessä videot on (mp4/mkv/ts jne.)? Matroska eli mkv on yleensä nopea hyppiä.

Rikkinäisellä tiedostolla hyppely on hidasta.

 

[Diizzel]

Missä kääreessä videot on (mp4/mkv/ts jne.)? Matroska eli mkv on yleensä nopea hyppiä.

Rikkinäisellä tiedostolla hyppely on hidasta.

Kääreenä on mp4, jotta yhteensopivuus Applen laitteiden kanssa olisi parasta. Sama kääre siis sekä x265:llä että vce:llä koodateessa.

 

[Pertti Kosunen]

Kääreenä on mp4, jotta yhteensopivuus Applen laitteiden kanssa olisi parasta. Sama kääre siis sekä x265:llä että vie:llä koodateessa.

ffmpeg -i input.mp4 -c copy output.mp4

Kokeile remuxata tiedosto vaikka ffmpeg:llä, toimiiko paremmin?

 

[Diizzel]

ffmpeg -i input.mp4 -c copy output.mp4

Kokeile remuxata tiedosto vaikka ffmpeg:llä, toimiiko paremmin?

Mihin tämä koodin pätkä tulisi siis laittaa? Voisin kokeilla huomenissa, kunhan pelikone vapautuu taas noista koodaushommista, kun laitoin sen pakkaamaan h264:ksi kun x265 on niin turhauttavan hidasta jopa tuolla Ryzenillä.

 

[Lagittaja]

Mihin tämä koodin pätkä tulisi siis laittaa? Voisin kokeilla huomenissa, kunhan pelikone vapautuu taas noista koodaushommista, kun laitoin sen pakkaamaan h264:ksi kun x265 on niin turhauttavan hidasta jopa tuolla Ryzenillä.

Komentokehotteeseen.

 

[JiiPee]

Originaali tässä
http://jell.yfish.us/media/jellyfish-110-mbps-hd-hevc.mkv

Jonka sitten pakkasin Handbraken kanssa 2 kertaan.
Toinen pakkaus slow presetillä h265 softa ja toinen AMD:n h265 raudalla quality.
Molemmissa 10000bps ja 2-pass.

Toinen otti aikaa 6min 4sec ja toinen hurahti 46sec.

Dropbox - Jellyfish-1.mkv
Dropbox - Jellyfish-2.mkv

Kartokaas eroista ja kumpi on kumpi sen enempiä headereita nuuskimatta.

 

[koodi]

Toi on ehkä vähän huono sample testaamiseen, mutta ei noista kyllä hirveästi laatueroa osu silmään ainakaan väsyneenä.
Ite totesin joskus ennen ryzeniä, että näyttiksellä(nvenc) pakkaantuu melkoista haipakkaa 4/8 prossuun verrattuna, artefakteja ja ihmeellisyyksiä väreissä oli kyllä aika reippaasti vaikka laatua nosteli. Päädyin sitten kuitenkin käyttämään softa x264:sta.

Nykyään tuleekin 9 kertaa 10:stä käytettyä suoraan adoben media encoderia joka kyllä MPE:llä osaa rendailla näyttiksellä jotain, mutta tämä vain vähän keventää prossun taakkaa, mutta laatu ei kärsi. 8/16 prossu on kyllä FHD kaman kanssa jo ihan pätevä.

 

[JiiPee]

Toi on ehkä vähän huono sample testaamiseen, mutta ei noista kyllä hirveästi laatueroa osu silmään ainakaan väsyneenä.
Ite totesin joskus ennen ryzeniä, että näyttiksellä(nvenc) pakkaantuu melkoista haipakkaa 4/8 prossuun verrattuna, artefakteja ja ihmeellisyyksiä väreissä oli kyllä aika reippaasti vaikka laatua nosteli. Päädyin sitten kuitenkin käyttämään softa x264:sta.

Nykyään tuleekin 9 kertaa 10:stä käytettyä suoraan adoben media encoderia joka kyllä MPE:llä osaa rendailla näyttiksellä jotain, mutta tämä vain vähän keventää prossun taakkaa, mutta laatu ei kärsi. 8/16 prossu on kyllä FHD kaman kanssa jo ihan pätevä.

Mjoo. Lähinnä toi nopeus ainakin ittellä 4-coren kanssa kärsii niin paljon kun softalla pakataan että hermo menee. Toi oli nyt tarkoituksella väännetty slow joka todellakin on slow tällä kivellä.
Logista kun kattoo niin
GPU: work: average encoding speed for job is 42.216099 fps
CPU: work: average encoding speed for job is 3.627989 fps

Ja tuossa CPU:lla käytin vielä turbo first pass. Ilman sitä olis ollu vielä hitaampi. Jos tällä kivellä jotain meinaa softalla pakkailla, niin pitää mennä sitten jo fast presetistä alaspäin.

Niin ja toi GPU pakkaus ei edes ole maksimi nopeudella mitä tää Vega 56 pystyisi tarjoamaan. Loppuu tästä 4-core kivestä jerkku syöttää tuota korttia, en tiijä onko se originaalin purku vai mihinkö se koko CPU teho katoaa myös GPU pakkausta käytettäessä.
Testasin tuossa niin ihan sama käyttääkö GPU:lla speed, balanced vaiko quality presettiä niin aika on ihan sama.

Toki toi nyt on vasta saatu tuohon handbrakeen niin voihan siinä olla vielä bugeja.

 

[vetu104]

Mihin tämä koodin pätkä tulisi siis laittaa? Voisin kokeilla huomenissa, kunhan pelikone vapautuu taas noista koodaushommista, kun laitoin sen pakkaamaan h264:ksi kun x265 on niin turhauttavan hidasta jopa tuolla Ryzenillä.

Jos käytät windowsia, niin pitää lisätä ffmpeg PATHiin, jotta se toimisi pelkällä komennolla mistä sijainnista tahansa. Jos et lisää ffmpegia PATHiin, niin siihen pitää viitata komentokehotteessa koko polulla. Eli:

1. Lataa ffmpeg (zip-tiedosto)
   
2. Pura haluamaasi paikkaan
3. Avaa komentokehote (vaikka win+r > cmd)
4. Suunnista "cd" komennolla kansioon, josta input mp4 tiedosto löytyy. (esim. "cd C:\Users\Matti\Videos")
5. Anna ylemmässä viestissä mainittu komento, mutta viittaa ffmpeg:iin koko polulla. (esim "C:\Users\Matti\ffmpeg4.0\bin\ffmpeg.exe -i input.mp4 -c copy output.mp4")

 

[Pertti Kosunen]

Mihin tämä koodin pätkä tulisi siis laittaa? Voisin kokeilla huomenissa, kunhan pelikone vapautuu taas noista koodaushommista, kun laitoin sen pakkaamaan h264:ksi kun x265 on niin turhauttavan hidasta jopa tuolla Ryzenillä.

Builds - Zeranoe FFmpeg

Tuolta saa Windows-käännökset.

@echo off
C:\Bin\ffmpeg.exe -i "%1" -c copy -scodec mov_text "%~n1-remux.mp4"

Tallenna tuo vaikka työpöydälle mp4-remux.bat tiedostoon niin voit vetää ja pudottaa video-tiedostoja mp4-remux.bat kuvakkeen päälle ja remuxatut videot tallentuvat samaan paikkaan alkuperäisten kanssa (C:\Bin\ffmpeg.exe tilalle ffmpeg.exe sijainti koko polun kanssa).

 

[Diizzel]

Jos käytät windowsia, niin pitää lisätä ffmpeg PATHiin, jotta se toimisi pelkällä komennolla mistä sijainnista tahansa. Jos et lisää ffmpegia PATHiin, niin siihen pitää viitata komentokehotteessa koko polulla. Eli:

1. Lataa ffmpeg (zip-tiedosto)
   
2. Pura haluamaasi paikkaan
3. Avaa komentokehote (vaikka win+r > cmd)
4. Suunnista "cd" komennolla kansioon, josta input mp4 tiedosto löytyy. (esim. "cd C:\Users\Matti\Videos")
5. Anna ylemmässä viestissä mainittu komento, mutta viittaa ffmpeg:iin koko polulla. (esim "C:\Users\Matti\ffmpeg4.0\bin\ffmpeg.exe -i input.mp4 -c copy output.mp4")

Builds - Zeranoe FFmpeg

Tuolta saa Windows-käännökset.

@echo off
C:\Bin\ffmpeg.exe -i "%1" -c copy -scodec mov_text "%~n1-remux.mp4"

Tallenna tuo vaikka työpöydälle mp4-remux.bat tiedostoon niin voit vetää ja pudottaa video-tiedostoja mp4-remux.bat kuvakkeen päälle ja remuxatut videot tallentuvat samaan paikkaan alkuperäisten kanssa (C:\Bin\ffmpeg.exe tilalle ffmpeg.exe sijainti koko polun kanssa).

Kiitokset näistä joka päivä oppii näköjään yhä uutta Windowsin maailmassa, varsinkin nykyään enemmän Macia käyttävänä! Sain remuxauksen toimimaan, mutta hakuajat ovat yhä sigun pöytäkoneellakin skippailtuna useita sekunteja, kun taas x265:lla pakattuna hakuajat olivat käytännössä olemattomat. Tämä vain korostuu NASsin omalla video station ohjelmalla toistettuna, kun decoodauksen hoitaa sillon NAS.

Päädyin lopulta jatkamaan leffojen siirtämistä h264:lla, kun niiden nopeus oli x264:lla hyvinkin riittävä Ryzenini kanssa, minkä lisäksi myöskään koko ei ollut liian suuri verrattuna VCE:lla pakattuihin h265:siin. x265 pakattu meni toki pienempään tilaan, mutta pakkausajan kustannuksella. x264 antaa siis tässä nyt parhaan kompromissin ajan ja tilan suhteen, kun huomasin pakanneeni vanhemmat leffani liian huonoilla ääniasetuksilla ja joudun aloittamaan kuitenkin alusta. Toimiipahan videot paremmin myös tällä 2015 macbookilla, jossa ei vielä rautapurkua hevcille ole.

 

[Pertti Kosunen]

Tarkista MediaInfolla mitä eroja nykivällä ja nykimättömällä saman formaatin videoilla on?

 

[Diizzel]

Tarkista MediaInfolla mitä eroja nykivällä ja nykimättömällä saman formaatin videoilla on?

Mulla ei ole enää x265 pakattuja tiedostoja tallessa, sillä poistin ne tajuttuani audioformaatin heikkouden ja päätettyäni siirtää ne uusiksi, joten ei ole mihin verrata. Taidan omalta osaltani luovuttaa tän selvittämisessä. Voi hyvinkin olla että handbraken vce-pakkauksessa on vielä jotain hierottavaa. Toisaalta voi olla, että näyttis pakkaa videon jollakin tavalla vahvemmin, kuin aiemmin käyttämäni x265-asetukset (joiden käytöstä on siis aikaa jo puolisen vuotta), minkä seurauksena toistettaessa purku vie enemmän aikaa. Ite video siis pyörii kyllä sulavasti ja käynnistyy soimaan muutamissa sekunneissa, eli käytännön katselukokemusta se ei pilaisi, kun harvemmin oikeasti tulee hypittyä tuntia eteenpäin elokuvassa. Muutamien kymmenien sekuntien hypyt myös onnistuivat täysin sulavasti.

Edit: Tai no ihan sama. En mä osaa antaa asian olla, vaikka todennäköisesti tulenkin nyt tuota x264:ää käyttämään kun mac sitä tukee. Laitoin handbraken pakkaamaan yhtä elokuvaa, jonka pakkaamaton versio NASilla yhä oli. Siitä tulee nyt superfast presetin x265 (en yleensä käytä superfastia, mutta nyt säästän aikaa) ja samasta tiedostosta teen myös VCE:llä tehdyn version. Laitan media infon antamat tiedot tänne myöhemmin, kunhan nuo pakkaukset ovat valmiit.

 

[Diizzel]

Noniin kone oli hoitanu pakkaukset taustalla ja nyt on mediainfon tiedot molemmista pakkauksista. Testasin myös uudestaan scrobbausta ja kyllä toi x265 on käytännössä instant, kun taas vce jää pohtimaan.

 

[Pertti Kosunen]

Näköjään tuo vce ei tallena noita tarkempia tietoja metadataan, Format profile: Main @ level 6.2 vs. 4 näyttää suurimmalta erolta, liekö tuolla sitten niin paljon merkitystä.

High Efficiency Video Coding tiers and levels - Wikipedia

 

[JiiPee]

Näköjään tuo vce ei tallena noita tarkempia tietoja metadataan, Format profile: Main @ level 6.2 vs. 4 näyttää suurimmalta erolta, liekö tuolla sitten niin paljon merkitystä.

High Efficiency Video Coding tiers and levels - Wikipedia

Mahtaisikohan tuo ongelma johtua siitä että VCE ei tue B-frameja?

 

[Pertti Kosunen]

Tietääkseni I-framet sisältävät koko kuvan, P- ja B-framet ovat interpoloituja. B-framet ovat monimutkaisimpia, ne perustuvat sekä edelliseen että seuraavaan I/P-frameen. Luulin, että noita I-frameja on nykysillä koodekkeilla usein, monta kappaletta sekunnissa, mutta ilmeisesti niitä voi olla paljon harvemminkin. Jos videotoistin tottelee tarkasti hyppypaikkoja, niin se voi joutua laskemaan paljonkin noita P/B-frameja I-framen jälkeen, että voi alkaa näyttämään kuvaa juuri oikeasta paikasta ja tämä voi olla syynä hyppyjen hitauteen.

Noiden B-kuvien pois jättäminen on luultavasti yksi isoimmista pakkausnopeuden nostajista ja vähentää myös muistin käyttöä.

 

[Yeenoghu]

Tietääkseni I-framet sisältävät koko kuvan, P- ja B-framet ovat interpoloituja. B-framet ovat monimutkaisimpia, ne perustuvat sekä edelliseen että seuraavaan I/P-frameen. Luulin, että noita I-frameja on nykysillä koodekkeilla usein, monta kappaletta sekunnissa, mutta ilmeisesti niitä voi olla paljon harvemminkin. Jos videotoistin tottelee tarkasti hyppypaikkoja, niin se voi joutua laskemaan paljonkin noita P/B-frameja I-framen jälkeen, että voi alkaa näyttämään kuvaa juuri oikeasta paikasta ja tämä voi olla syynä hyppyjen hitauteen.

Juu, aika lähelle meni. I-frame on tosiaan frame jota ei ole interpoloitu, mutta koodekista riippuen IDR/keyframe on se frame, jonka perusteella dekooderi valitsee, mistä toisto esim. pikakelauksen jälkeen aloitetaan. Monesti toki I-frame ja keyframe ovat sama frame. Keyframet luodaan enemmänkin muutaman sekunnin välein kuin muutama sekunnissa. Riippuu tietenkin täysin käytettävästä koodekista ja asetuksista.

Aika hyvin selitetty täällä: https://www.quora.com/What-is-the-difference-between-an-I-Frame-and-a-Keyframe-in-video-encoding

Lisähaasteena joidenkin editorien kanssa on, että leikkaaminen on erittäin suositeltavaa vain keyframien kohdalla, tai muuten lipsync menee vituralleen. Jaa mistäkö...?

 

[JiiPee]

Nyt kun ollaan päästy syvällisempään mutusteluun niin ajoin ihan huvikseni ffprobella läpi noi softalla ja VCE:llä pakatut pätkät. Molemmat alkaa I-framen kanssa jonka jälkeen VCE pakattu on pelkkää P-framee kun taas softalla pakatussa 3/4 on B-frameja ja 1/4 P-frameja.

Tein sitten vielä käppyrät noista minkä kokosia framet on ja tulos oli aika jännittävän näköinen.

Tää on softalla

Tää on VCE

Ihmetyttää toi softapakkauksen sahaaminen suuresti.

 

[zepi]

No siis B-framejen etu on nimenomaan se, että ne ovat todella pieniä ja se säästää sitten enemmän tilaa niille I ja P frameille.

X265 ilman B:tä on vähän niin ja näin, paras hyöty pakkaustiheydessä jäänee saamatta.

 

[Agent_007]

Näytönohjainpuolella ei taida vielä olla HEVC-pakkaustoteutusta, joka tukisi B-frameja. Ja tosiaan optimaalinen B-framejen hyödyntäminen videota pakatessa vaatii kohtullisen monen framen puskurin, joten näytönohjainten osalta B-framejen hyödyntäminen on hieman hankalaa.

Jos videotoistin tottelee tarkasti hyppypaikkoja, niin se voi joutua laskemaan paljonkin noita P/B-frameja I-framen jälkeen, että voi alkaa näyttämään kuvaa juuri oikeasta paikasta ja tämä voi olla syynä hyppyjen hitauteen.

Juurikin näin. Sama ongelma koskee myös frame skippausta taaksepäin, jolloin pitää pahimmassa tapauksessa hypätä edelliseen GOP:iin ja toistaa siitä kaikki framet läpi, että saa sen oiken kuvan aikaiseksi.

 

[JiiPee]

Nyt näyttäisi olevan tuki myös nvenc.

Add NVEnc encoder. (Round 3) (#1437) · HandBrake/HandBrake@dbf8986

Testatkaas joku miten toimii.