Handbrake ja rautaencode

JiiPee

JiiPee

Liittynyt
21.06.2017
Viestejä
7 266
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
 
Mutta mikä on luopputuotteen laatu suhteessa siihen cpu-enkoodaukseen?
 
zepi sanoi:
Mutta mikä on luopputuotteen laatu suhteessa siihen cpu-enkoodaukseen?
Napsauta laajentaaksesi...

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ä.
 
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.
 
Elvis Jagger sanoi:
Eli sekä GPU- että CPU-enkoodauksella saa yhtä huonoa tai hyvää, mutta ero on se kauanko siihen menee.
Napsauta laajentaaksesi...
Yleensä rauta-pakkaus ei ole päässyt yhtä hyvään laatuun kuin x264/x265 jotka kykenevät jopa parempaan jälkeen kuin kaupalliset kilpailijat.
 
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.
 
Pertti Kosunen sanoi:
Yleensä rauta-pakkaus ei ole päässyt yhtä hyvään laatuun kuin x264/x265 jotka kykenevät jopa parempaan jälkeen kuin kaupalliset kilpailijat.
Napsauta laajentaaksesi...
En tosiaan tainnut tajuta. Tämä siis onkin joku oma implementaatio kun luulin että se vaan joku rajapinta jolla ajetaan sitä samaa codecia.
 
Lagittaja sanoi:
Joku toki voisi sanoa että arkistoinnissa alkuperäinen olisi paras mutta ei minulla niin paljon ole kiintolevytilaa..
Napsauta laajentaaksesi...
Levytila on nykyään halpaa, ripatulle datalle joka on helpohkosti lueattavissa uudelleen optisilta kiekoilta ei kannata rakentaa liian hienoja tallennusvälineitä (ECC/ZFS jne.).
 
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.
 
Missä kääreessä videot on (mp4/mkv/ts jne.)? Matroska eli mkv on yleensä nopea hyppiä.

Rikkinäisellä tiedostolla hyppely on hidasta.
 
Pertti Kosunen sanoi:
Missä kääreessä videot on (mp4/mkv/ts jne.)? Matroska eli mkv on yleensä nopea hyppiä.

Rikkinäisellä tiedostolla hyppely on hidasta.
Napsauta laajentaaksesi...
Kääreenä on mp4, jotta yhteensopivuus Applen laitteiden kanssa olisi parasta. Sama kääre siis sekä x265:llä että vce:llä koodateessa.
 
Viimeksi muokattu:
Diizzel sanoi:
Kääreenä on mp4, jotta yhteensopivuus Applen laitteiden kanssa olisi parasta. Sama kääre siis sekä x265:llä että vie:llä koodateessa.
Napsauta laajentaaksesi...
Koodi: 
ffmpeg -i input.mp4 -c copy output.mp4

Kokeile remuxata tiedosto vaikka ffmpeg:llä, toimiiko paremmin?
 
Pertti Kosunen sanoi:
Koodi: 
ffmpeg -i input.mp4 -c copy output.mp4

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

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ä.
 
Diizzel sanoi:
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ä.
Napsauta laajentaaksesi...

Komentokehotteeseen.
 
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ä.
 
koodi sanoi:
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ä.
Napsauta laajentaaksesi...

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.
 
Diizzel sanoi:
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ä.
Napsauta laajentaaksesi...

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")
 
Diizzel sanoi:
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ä.
Napsauta laajentaaksesi...
Builds - Zeranoe FFmpeg

Tuolta saa Windows-käännökset.

Koodi: 
@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).
 
vetu104 sanoi:
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")
Napsauta laajentaaksesi...
Pertti Kosunen sanoi:
Builds - Zeranoe FFmpeg

Tuolta saa Windows-käännökset.

Koodi: 
@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).
Napsauta laajentaaksesi...

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 sanoi:
Tarkista MediaInfolla mitä eroja nykivällä ja nykimättömällä saman formaatin videoilla on?
Napsauta laajentaaksesi...
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.
 
Viimeksi muokattu:
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.
VCE pakattu.png x265 pakattu.png
 
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öä.
 
Pertti Kosunen sanoi:
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.
Napsauta laajentaaksesi...
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ö...?
 
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.

chart (1).png

Tää on softalla

chart (2).png


Tää on VCE

Ihmetyttää toi softapakkauksen sahaaminen suuresti.
 
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.
 
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.

Pertti Kosunen sanoi:
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.
Napsauta laajentaaksesi...
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.
 
Kirjaudu tai rekisteröidy kirjoittaaksesi tänne.

Uutiset

Uutisia lyhyesti

Uusimmat viestit

Statistiikka

Viestiketjuista
261 703
Viestejä
4 544 706
Jäsenet
74 833
Uusin jäsen
Kanadanhanhi

Hinta.fi

Back
Ylös Bottom