Kdenlive, H.264 ja i7: Miten sais kaiken irti renderissä

[uhappo]

Hoblaa!

Mulla on H.264 renderissä tommonen ketju:

Koodia: [Valitse]

f=mp4 hq=1 acodec=libmp3lame ab=192k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=10000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=2
Ei kyllä ota prossusta semmosta tehoa irti mitä pitäis. Jos tohon loppuun lisää threads=2, niin nopeutuu melkein puolella ja näyttäis siltä että säkeistää tai threadit on kunnolla käytössä, mutta jumittaa 99% kohdalle ja eipä nyt taida siitä pidemmälle mennä. Mitähän pitäis tehdä että sais koneen lentämään, siis muuallekin kuin ikkunasta pihalle...

Käytössä siis karmic ja 0.7.6 Kdenlive

[Asmo Koskinen]

Ei kyllä ota prossusta semmosta tehoa irti mitä pitäis.

En osaa auttaa, mutta otin itse käyttöön Cinelerran, kun Karmicissa MTS-tiedostojen kanssa tuli ongelmia. Muutan MTS-tiedostot MOV-tiedostoiksi. Cinelerra osaa ne hienosti.

Käytän tällaista skriptiä.

http://code.google.com/p/hdffxvrt/

Ehkä tuosta skriptistä löytyy lisää (ffmpeg) optimointeja, vaikka et haluaisikaan MOV-tiedostoa? Kannattaa varmaan kääntää viimeisin SVN-versio ffmpeg-ohjelmasta?

Projektin aloitusviesti.

"The above uses a pipeline so that multicore machines see benefit; but in truth one core will be maxed-out while the other is mostly idle – decode-to-raw is cheap and fast – so the script is written so that you can do something crazy like:

$ hdffxvrt *.mts & # background process 1
$ hdffxvrt *.mts & # background process 2
[--]
The only dependency is “ffmpeg” (I am using SVN-r15674) with AAC and other goodness built into it; that is left as an exercise for the reader. No other compilation is required."

http://www.crypticide.com/dropsafe/article/2657

Ystävällisin terveisin Asmo Koskinen.

[uhappo]

Mä en oo ite tarvinnu MTS:ää ollenkaan koska ei oo itellä semmosta kameraa. Tosin tsekkasin just MTS-pätkää Kdenlivessä ja ei jostain syystä ihan niin helposti toimi kuin muut formaatit.

Anyway, mä oon Cinelerraa joskus kokeillu, ja ei kyllä sovi mulle. Oon käyttäny jo jonkin aikaa Kdenliveä ja alkuihmettelyn jälkeen se on kyllä todella hyvä ohjelma. Haluiaisin tykätä Openshotista vielä enemmän, mut se on vielä niin kesken, kaatuu herkemmin ja ainakaan ite en osaa sillä tehdä onnistuneita rendereitä. Toisin kuin Kdenlivessä.

Velipoojalla on MTS:ää ulostyrkkäävä kamera, ja se muuntaa aina filminsä AVI:ks tällä ohjeella: http://ubuntuforums.org/showthread.php?t=1045153

En sit tiedä onko noissa SVN-versioissa jotain eroa ja toimiiko toi enää nowadays niin hyvin, mut onhan tolle MTS->AVI (tai joku muu formaatti) -rintamalle tullu noita skriptejä ja jargoneita millä saa käännettyä älylliseen muotoon MTS-kamat.

Kiitti vinkistä anyway, mutta metsästän edelleen Kdenlive-kysymyksiini vastauksia..! Rok!

[nm]

Hoblaa!

Mulla on H.264 renderissä tommonen ketju:

Koodia: [Valitse]

f=mp4 hq=1 acodec=libmp3lame ab=192k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=10000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar pass=2
Ei kyllä ota prossusta semmosta tehoa irti mitä pitäis. Jos tohon loppuun lisää threads=2, niin nopeutuu melkein puolella ja näyttäis siltä että säkeistää tai threadit on kunnolla käytössä,

Käytä parametria threads=0, niin x264 valitsee itse sopivan määrän säikeitä (neljälle ytimelle 6 säiettä, tai 12, jos prosessorin hypersäikeistys on päällä).

Tuosta listasta puuttuu myös useita muita tärkeitä asetuksia. Tiedoston /usr/share/ffmpeg/libx264-default.ffpreset mukaan olisi hyvä lisätä ainakin nämä:

Koodia: [Valitse]

cmp=+chroma
partitions=+parti8x8+parti4x4+partp8x8+partb8x8
me_method=hex
me_range=16
g=250
keyint_min=25
sc_threshold=40
i_qfactor=0.71
bf=3
refs=3
directpred=1
flags2=+mixed_refs+wpred+dct8x8+fastpskip
Lisäksi esiasetuksessa voi olla wpredp=2, jos käytössä on uusi x264:n versio, mutta se aiheuttaa ongelmia joidenkin dekooderien kanssa. wpredp=1 on turvallisempi.

Nämä asetukset saa käyttöön myös parametrilla vpre=default. Vastaavasti voi käyttää myös muita /usr/share/ffmpeg-hakemistossa olevia libx264-esiasetuksia, kuten vaikkapa vpre=hq:ta.

Kaksivaiheisen (2-pass) pakkauksen sijaan suosittelisin CRF:ää, jos videota ei ole tarkoitus mahduttaa tiettyyn tilaan, kuten DVD-levylle. Lue myös tämä ohje: http://rob.opendot.cl/index.php/useful-stuff/ffmpeg-x264-encoding-guide/

mutta jumittaa 99% kohdalle ja eipä nyt taida siitä pidemmälle mennä.

Olisikohan tämä vika Kdenliven puolella? Yksi vaihtoehto on ottaa video ulos häviöttömästi (tai lähes häviöttömästi) jossain toisessa formaatissa ja pakata sitten uudelleen esimerkiksi HandBrakella, mutta tämä vaatii aika paljon vapaata levytilaa.

[uhappo]

Nyt alkoi lyydia kirjoittamaan:

Tommosella rimpsulla

Koodia: [Valitse]

f=mp4 hq=1 acodec=libmp3lame ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=4000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=22
736 megan (3:33 minuuttia) dv-pätkästä tulee 45 megan tiedosto about 53 sekunnissa. Siis KDENlivestä kun renderöi hän.

Kun muuttaa tossa rimpsussa crf:n arvoksi 15 niin menee about 5 sekuntia pidempään ja tiedoston koko kasvaa kolminkertaiseksi, mutta kuvanlaatu on parempi. Toi mun videokamera on JVC:n halpisversio ja kuvanlaatu sen mukaista, joten toi 15-arvo on turhaa, joku 18-19 on ihan passeli.

Tässä conky-mittarin lukemia aktionista:

[nm]

Nyt alkoi lyydia kirjoittamaan:

Tommosella rimpsulla

Koodia: [Valitse]

f=mp4 hq=1 acodec=libmp3lame ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=4000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=22

Suosittelisin käyttämään asetusta vpre=default tai vpre=hq, tai sitten asettamaan vastaavat parametrit manuaalisesti, kuten neuvoin edellisessä viestissäni. Tällä hetkellä menetät todella suuren osan x264:n hyödyistä, kun et anna sen käyttää B-frameja ja useita referenssikuvia, ja partitio-analyysit ovat pois päältä.

[mrl586]

Tässä conky-mittarin lukemia aktionista:

Montako prossua tuossa myllyssä on?

[timbba]

Lainataas threadia kun liittyy kdenliveen. Mulla on sunabin ppa:sta asennettuna Kdenlive 0.7.6. Ubuntussa on ilmeisesti disabloitu aac encoder, joten saakos tuon aac encoderin käyttöön jotenkin helposti kdenlivessä vai onko ainut ratkaisu ffmpegin kääntö itse? Tällä hetkellä purkkaratkaisuna mulla on oma scripti, joka konvertoi H264/mp3 -tiedoston H264/AAC -tiedostoksi (flash kun ei osaa H264/mp3 muotoa)..

[nm]

Lainataas threadia kun liittyy kdenliveen. Mulla on sunabin ppa:sta asennettuna Kdenlive 0.7.6. Ubuntussa on ilmeisesti disabloitu aac encoder, joten saakos tuon aac encoderin käyttöön jotenkin helposti kdenlivessä vai onko ainut ratkaisu ffmpegin kääntö itse? Tällä hetkellä purkkaratkaisuna mulla on oma scripti, joka konvertoi H264/mp3 -tiedoston H264/AAC -tiedostoksi (flash kun ei osaa H264/mp3 muotoa)..

FAAC ja FFmpegin oma AAC-enkooderi tuottavat heikompaa laatua kuin LAME, joten jos mahdollista, ääni kannattaa pitää MP3-muodossa tai pakata erikseen NeroAacEncillä.

[timbba]

FAAC ja FFmpegin oma AAC-enkooderi tuottavat heikompaa laatua kuin LAME, joten jos mahdollista, ääni kannattaa pitää MP3-muodossa tai pakata erikseen NeroAacEncillä.

Tuota FAACia olinkin jo käyttänyt omassa scriptissä, joten pitänee latailla tuo Neron encooderi ja korvata FAAC sillä. Flashiin tarvii tuon aac:n joten sen takia se on itselle välttämätön.

[uhappo]

Koodia: [Valitse]

f=mp4 hq=1 acodec=libmp3lame ab=128k ar=48000 pix_fmt=yuv420p vcodec=libx264 minrate=0 b=4000k b_strategy=1 subcmp=2 cmp=2 coder=1 flags=+loop flags2=dct8x8 qmax=51 subq=7 qmin=10 qcomp=0.6 qdiff=4 trellis=1 aspect=%dar threads=0 crf=22Lisäsin tohon rimpsuun ton vpre=default ja kokeilin tällä mun läppärillä, siis 2ghz dual core AMD Turion. About 2:30 minuutin pätkän renderiin meni reilu 8 minuuttia aikaa, joten kyllä tossa i7-myllyssä "hieman" enemmän on vääntöä... Heh. Pitää vaan olla tyytyväinen että toimii, en vaan sit tiedä miten sen turboboostin kanssa on, missä se vois hypätä kehiin ja hyppääkö se ubuntussa jne, mut I'm oikein tyytyväinen hommaan ihan näinkin.

Niin, siis B-frame/multiple referenssikuvat/partitio-analyysit ei siis oo päällä jos niitä ei tohon rimpsuun lisää kuten edellä on mainittu, tuskin toi vpre-vipu niitä kaikkia ottaa käyttöön? Mites noi vaikuttaa kuvan laatuun, tai nopeuteen?

Ja tänään Ukko-Tahkolle soittamaan, kaikki kynnellä olijat mukaan tsembaloihin...

[nm]

Niin, siis B-frame/multiple referenssikuvat/partitio-analyysit ei siis oo päällä jos niitä ei tohon rimpsuun lisää kuten edellä on mainittu, tuskin toi vpre-vipu niitä kaikkia ottaa käyttöön?

Listaamani parametrit olivat suoraan tiedostosta /usr/share/ffmpeg/libx264-default.ffpreset (osa oli komentorivilläsi jo valmiina), jolloin vpre=default ottaa ne kyllä käyttöön -- tai ainakin pitäisi, jos käytössä on riittävän uusi x264 ja FFmpeg.

Mites noi vaikuttaa kuvan laatuun, tai nopeuteen?

Laadun pitäisi olla huomattavasti parempi. Arvioisin, että tiedostokoossa mitattuna vpre=default on noin 25-50 % parempi verrattuna aluksi listaamiisi parametreihin, eli voit saada joissain tapauksissa melkein puolet pienempiä tiedostoja samalla laadulla. Osa parametreista hidastaa pakkausta, mutta tuskin liikaa. vpre=hq voi myös olla ihan järkevä esiasetus Core i7:llä.