ffmpeg käyttää vain yhtä ydintä

[rs]

hei, yritin muuttaa koneellani olevia elokuvia vp9 pakatuiksi videoiksi ffmpeg:llä. jostain syystä se käyttää vain yhtä ydintä, ja se tekee transkoodauksesta toivottaman hidasta. pahimmillaan sen nopeus oli 4fps jolla muutaman tunnin elokuvan muuttamiseen menee jokseenkin turhastuttavan pitkä aika. yritin käyttää -threads 4 parametriä, mutta sillä ei ollut mitään vaikutusta. käytin aluksi ubuntu 16.04 repojen tarjoamaa versiota, mutta käänsin sen eilen vielä sorsasta libvpx koodekin kera, ilman mitään vaikutusta. onko tuo ongelma tuossa koodekissa vai missä, ettei ffmpeg käytä montaa ydintä? tarkoitus on siis muuntaa elokuvia sen kokoisiksi, että streamaaminen kännykkään onnistuisi paremmin. vai olisiko tuohon käyttöön joku toinen koodekki parempi? vp9 ainakin olisi ainakin tehokkaampi/laadukkaampi kuin h264 ja käsittääkseni pitäisi toimia androidin kanssa hyvin

[Tomin]

libvpx (VP8 ja VP9) ei ole kovin hyvä säikeistämään ja taitaa tosiaan oletuksena käyttää vain yhtä säiettä. x264 (h264) on paljon parempi siinä ja skaalautuu paremmin. Käsittääkseni syy on siinä, että Google (YouTube) voi joka tapauksessa muuntaa monta videota yhtä aikaa, joten heillä ei ole kovinkaan paljoa kiinnostusta kehittää säikeistystä. Kännykälle h264 on varmaan oikein sopiva, sille luultavasti löytyy laitteistotukikin, jolloin akkukeston saa vähän paremmaksi. Muuten toki olisi kiva suositella vapaita koodekkeja kuten VP9. Ehkä AV1:stä sitten joskus.

Luulisin, että tarvitset -threads=N-argumentin (korvaa N säikeiden lukumäärällä).

[rs]

ahaa, jotain pieniä pätkiä ehdin vain jo yön aikana transkoodata tuolla vp9:llä ja houkutteli sen tuoma tiedostokoon pienyys hyvällä laadulla joka puolestaan olisi ollut ihan hyvä asia kännykkään streamatessa mutta ehkä täytyy sitten vain pysytellä tuossa h264

[nm]

Kannattaa lukea ohjeita täältä: http://wiki.webmproject.org/ffmpeg/vp9-encoding-guide

Tarvitset -threads N:n lisäksi parametrin -tile-columns M:

Multi-threaded encoding may be used if -threads > 1 and -tile-columns > 0.

Tile-columns ja -frame-parallel 1 auttavat myös dekoodauksen säikeistyksessä:

Most of the current VP9 decoders use tile-based, multi-threaded decoding. In order for the decoders to take advantage of multiple cores, the encoder must set tile-columns and frame-parallel.

En osaa sanoa, onko tuolla vaikutusta rautapurun kanssa. Aika hyvin näyttäisi VP8/9 olevan tuettu uusimmissa mobiilisiruissa: http://wiki.webmproject.org/hardware/socs

Jotain tällaista ohjeen mukaista komentoriviä kuitenkin voisi kokeilla:

Koodia: [Valitse]

ffmpeg -i <source> -c:v libvpx-vp9 -pass 1 -b:v 1000K -threads 8 -speed 4 -tile-columns 6 -frame-parallel 1 -c:a libopus -b:a 64k -f webm out.webm
Säikeistyksellä voi olla pieni negatiivinen vaikutus laatuun(/bitrate). Jos sillä on merkitystä, tai jos libvpx ei säikeisty riittävän hyvin, kannattaa enkoodata useita videoita samanaikaisesti kuten isot pojat tekevät. 


[aiheen vierestä]
x265 on vielä jonkin verran VP9:ää tehokkaampi matalilla bitrateilla. Netflixin verrattain laajassa testissä x265 tuotti keskimäärin 20% pienempiä tiedostoja kuin libvpx:n VP9, kun laatu vakioitiin VMAF-metriikalla: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx

Korkeammalla pakkauslaadulla (yli 15 Mbps bitratella 1080p24-videolle) x264:ää on edelleen vaikea voittaa. VP9 ja x265 hävittävät kuvasta herkästi hienovaraisia tekstuureja, jotka x264 pystyy säilyttämään, kun käytettävissä on tarpeeksi bittejä. Aikoinaan sama ongelma ilmeni myös x264:ssä ja kaikissa muissakin H.264-enkoodereissa, mutta ongelma onnistuttiin ratkaisemaan x264:ään kehitetyllä psy-rd-mekanismilla. Periaatteessa sama algoritmi on toteutettu x265:ssä, mutta tulokset eivät ole olleet yhtä hyviä. Tosin UHD-videolla H.265:n isommat blokkikoot auttavat pakkauksessa niin paljon, että järkevillä bitrateilla x265 on yleensä paras saatavilla oleva enkooderi.

Enkoodauksen nopeus on sitten toinen juttu. x264 on hitaillakin säädöillä (-preset slower tai -preset veryslow) varsin vikkelä verrattuna libvpx:ään ja x265:een. Netflix voi käyttää hyvinkin hitaita pakkausparametreja, koska katalogissa on suhteellisen vähän videoita ja ne voidaan pakata hyvissä ajoin ennen julkaisua.
[/aiheen vierestä]

[rs]

hmmm ei ollut tuolla vaikutusta kyllä ytimien käyttöön... handbrake nähtävästi käyttää paremmin kaikkia ytimiä mistäköhän sekin lienee johtuvan. mutta minulla on kyllä vanha neliydinprossu (i5-760) joten voipi olla että olisi rautaostoksillekin pikkuhiljaa syytä lähteä 

miten tuollainen useiden videoiden enkoodaus tapahtuu samanaikaisesti? vain monta päätettä jossa ffmpeg vai saako ne putkitettua jotenkin yhteen komentoon?

[rs]

x265 on vielä jonkin verran VP9:ää tehokkaampi matalilla bitrateilla. Netflixin verrattain laajassa testissä x265 tuotti keskimäärin 20% pienempiä tiedostoja kuin libvpx:n VP9, kun laatu vakioitiin VMAF-metriikalla: http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx

Korkeammalla pakkauslaadulla (yli 15 Mbps bitratella 1080p24-videolle) x264:ää on edelleen vaikea voittaa. VP9 ja x265 hävittävät kuvasta herkästi hienovaraisia tekstuureja, jotka x264 pystyy säilyttämään, kun käytettävissä on tarpeeksi bittejä. Aikoinaan sama ongelma ilmeni myös x264:ssä ja kaikissa muissakin H.264-enkoodereissa, mutta ongelma onnistuttiin ratkaisemaan x264:ään kehitetyllä psy-rd-mekanismilla. Periaatteessa sama algoritmi on toteutettu x265:ssä, mutta tulokset eivät ole olleet yhtä hyviä. Tosin UHD-videolla H.265:n isommat blokkikoot auttavat pakkauksessa niin paljon, että järkevillä bitrateilla x265 on yleensä paras saatavilla oleva enkooderi.

matalista bitrateista nyt on kyse, 1-4mbps, olen kuitenkin käsittänyt että h265 dekoodaus ei ole kovin hyvin laitteissa tuettu. puhelimessa minulla on snapdragon 820. pikaisella googletuksella sen pitäisi kyllä ilmeisesti tukea h265 (mutta ei vp9 ainakaan tuon mukaan: https://www.qualcomm.com/products/snapdragon/processors/comparison mielestäni kyllä jollain muulla sivulla taas luki että tukisi vp9 mutta en nyt ota selkoa...), joten olisikohan tuo h265 siis kokeilemisen arvoinen?

[nm]

hmmm ei ollut tuolla vaikutusta kyllä ytimien käyttöön... handbrake nähtävästi käyttää paremmin kaikkia ytimiä mistäköhän sekin lienee johtuvan.

Handbrake käytti sitten eri enkooderia tai eri parametreja. Jos varmistit ulos saadusta videosta, että se tuotti VP9-videota webm-säiliössä, ero on varmaan parametreissa. Formaatin voit tarkistaa ffprobe-komennolla:

Koodia: [Valitse]

ffprobe tiedosto.webm

Testasin libvpx:ää ffmpegillä ja DVB-tallenteella (H.264-pakattua 1080p25-videota). Pass 1:ssä ei säikeistyksestä ollut apua, ja nopeus oli luokkaa 10 fps. Pass 2:ssa enkooderi kuormitti neljällä säikeellä 2,5 ydintä ja nopeus oli  6,3 fps. Yhdellä säikeellä nopeus jäi 3 fps:ään.

miten tuollainen useiden videoiden enkoodaus tapahtuu samanaikaisesti? vain monta päätettä jossa ffmpeg vai saako ne putkitettua jotenkin yhteen komentoon?

No vaikka tuolla tavalla monessa päätteessä samanaikaisesti. Itse tekisin videokokoelman uudelleenpakkaukseen skriptin, joka ottaa komentorivillä vastaan hakemiston tai listan tiedostonimiä ja pakkaa ne peräkkäin. Sitten jakaisin kokelman esim. neljään osaan ja syöttäisin kunkin osan eri päätteessä (tai mielellään screenissä) ajettavalle pakkausskriptille. Käsitellyt videot kannattaisi skriptissä merkata jollain tavalla tai siirtää eri paikkaan, jotta prosessin voi käynnistää helposti uudelleen.

Byobu on mukava ohjelma tuollaisiin tausta-ajoihin. Helpompi käyttää kuin screen tai tmux.

matalista bitrateista nyt on kyse, 1-4mbps, olen kuitenkin käsittänyt että h265 dekoodaus ei ole kovin hyvin laitteissa tuettu. puhelimessa minulla on snapdragon 820. pikaisella googletuksella sen pitäisi kyllä ilmeisesti tukea h265 (mutta ei vp9 ainakaan tuon mukaan: https://www.qualcomm.com/products/snapdragon/processors/comparison mielestäni kyllä jollain muulla sivulla taas luki että tukisi vp9 mutta en nyt ota selkoa...), joten olisikohan tuo h265 siis kokeilemisen arvoinen?

On se kokeilemisen arvoinen. H.265:n rautadekoodaustuki on suunnilleen samalla tasolla kuin VP9:n tuki, eli löytyy uusimmista viimeisen parin vuoden aikana julkaistuista piireistä. x265 on samalla laadulla suunnilleen yhtä nopea (tai hidas) kuin libvpx, mutta säikeistyy paremmin. x264 olisi kertaluokkaa nopeampi, mutta matalilla bitrateilla voi olla järkevää käyttää näitä uudempia formaatteja.

x264:n ja x265:n kanssa kannattaa käyttää crf-enkoodausta bitrate-pohjaisen 2-pass -enkoodauksen sijaan. Säästää aikaa ja laadun asettaminen on helpompaa. x264:llä pakkaisin 1080p-mobiilivideoita ehkä -crf 24:llä. Isolle ruudulle se on turhan matala laatu, mutta puhelimen näytöllä varmaan ok. x265:lle en osaa antaa suositusta, mutta muistaakseni crf:ää voi nostaa jonkin verran korkeammaksi. Kokeilemalla selviää.

[rs]

juu h265 näyttää käyttävän kaikkia ytimiä. melkoisen hyvinkin... ottaa prossu meinaan 98 astetta parhaimmillaan lämpöjä ei taida tehdä tuollainen kyllä hyvää sille... noh mutta täytyy jatkaa testailua ja etsiä sopivat asetukset

[nm]

juu h265 näyttää käyttävän kaikkia ytimiä. melkoisen hyvinkin... ottaa prossu meinaan 98 astetta parhaimmillaan lämpöjä ei taida tehdä tuollainen kyllä hyvää sille... noh mutta täytyy jatkaa testailua ja etsiä sopivat asetukset

Puhdista tuuletin ja jäähdytysripa. Jos ei auta, pitäisi vaihtaa lämpötahna jäähyyn. Intelin perusjäädyttimenkin pitäisi pitää lämmöt alle 70 asteessa täydellä kuormalla.