|
Divx 6.2.5 ja hidas rippausnopeus ja ongelma progressiivisen (?) DVD:n kanssa
|
|
|
Titan
Junior Member
|
16. heinäkuuta 2006 @ 17:32 |
Linkki tähän viestiin
|
|
Moro
Taas pitkästä aikaa pitää pyöräyttää yksi DVD leffa Divx:ksi. Huomasin että Divx on taas vaihteeksi päivittynyt ja hain testiin tuon uuden 6.2.5 version. DGMPGDec:n ja Avisynthin avustuksella kaikki sujui rutiinilla kunnes päästiin itse asiaan :)
Säädin Divx:n asetukset kuten ennenkin ja multipassilla meinaan homman tehdä (3 kertaisena). Profiiliksi laitoin luonnollisesti unconstrained että pääsee säätään ja pistin Quarter-Pixelin ja Global Motion compensationin päälle. Quantization on H.263 Optimized. Muihin en koskenut.
Tälläkin hetkellä kone jyystää rippiä kuin viimeistä päivää mutta nopeus on jostain syvältä. First pass menossa ja 1% saavuttamiseen menee noin puoli tuntia! Tätä menoa paketti on valmis joskus viikon päästä! :D
Konetehoa on nyt ainakin välttävästi, A64 San Diego 2.6GHz kellotettuna, luulis jotain sentään tapahtuvan.
Kokeilin muutella asetuksia (Quarter-Pixeliä ym pois) mutta eipä auta. Onko kenelläkään antaa vihjeitä miten homman sais toimimaan "hieman" nopeammin? :p
|
Senior Member
|
16. heinäkuuta 2006 @ 19:31 |
Linkki tähän viestiin
|
|
Eihän sinulla ole käytössä mikään "insane"-asetus liikkeen tunnistamiselle (motion estimation)? Se on ainakin yksi tekijä, mikä hidastaa enkoodausta aika paljon. Jos otit kerran QPelin pois päältä, niin sen pitäisi jo jonkin verran nopeuttaa enkoodaamista. Varmista myös, että koodekki käyttää kaikkia prosessorin tukemia optimointeja (MMX, SSE, SSE2, SSE3...). Liiallinen prosessorin kellottaminen voi myös aiheuttaa laskentavirheitä, ja siten hidastaa enkoodaamista.
Kannattaa myös kokeilla XviD:iä, jos se vaikka toimisi nopeammin.
|
|
Titan
Junior Member
|
16. heinäkuuta 2006 @ 19:50 |
Linkki tähän viestiin
|
|
Xvidillä homma toimi kuin rasvattu, First pass menee läpi melkein ruokatauolla ja ei loppuunkaan montaa tuntia mene. Prosussa on kellotusvaraa vielä vaikka kuinka ja näillä kelloilla on menty jo puoli vuotta. Aion vetää tän nyt käynnissä olevan session loppuun vaikka meni kuinka monta päivää :)
Mistä muuten DivX:n asetuksista noita optimointeja (SSE jne) voi tarkastella? Ei ole tullut sellaista valikkoa vielä eteen?
Sitten tarkistin asetuksia vielä...Frame Controllissa on päällä "Adaptive multiple consecutive" Jäi vähän epäselväksi sen tarkoitus mutta oletan että se ei aiheuta tahmaamista...
Mutta sitten Encoding mode on "Insane quality" kohdassa :) Tämä saattaa jo vaikuttaa MUTTA nyt täytyy tähdentää että olen ripannut vanhemmilla Divx 6.x codekeilla SAMOILLA asetuksilla. Olen aina käyttänyt tuota insane qualityä mutta ennen homma on toiminut silti HUOMATTAVASTI nopeammin.
Ja tässä lainaus viisaammalta hepulta:
"Here's what Gej (the creator of DivX) has to say about this setting:
It's all about your CPU speed and the time you want to allocate to encode a video, on a modern 2.8Ghz CPU insane encoding mode will take around a night (8 hours) for a 2pass, 100 minutes movie, if you can afford that kind of time, this is the best option quality wise, remember, you encode once and view it several times, this can make the time investment worth it."
Nykyinen rippausnopeus on siis aivan liian hidas. Laskeskelin että pelkästään 1.passin läpimenoon taitaa mennä jotain 16h... :)
|
Senior Member
|
17. heinäkuuta 2006 @ 06:20 |
Linkki tähän viestiin
|
Quote:
Mistä muuten DivX:n asetuksista noita optimointeja (SSE jne) voi tarkastella? Ei ole tullut sellaista valikkoa vielä eteen?
En tiedä. En itse käytä DivX-koodekkia ollenkaan. Jos siellä ei ole kyseisiä asetuksia, niin sillon DivX tunnistaa ne automaattisesti ja käyttää niitä.
Käytätkö mitään ylimääräisiä filttereitä AviSynth scriptissä? Ja kokeilitko XviD:iä tismalleen samalla scriptillä? Yksi vaihtoehto tuohon hitauteen on tietenkin se, että DivX:n kaverit ovat tehneet jotain muutoksia tuohon "insane"-asetukseen... Mene ja tiedä.
|
Staff Member
32 tuotearviota
|
17. heinäkuuta 2006 @ 08:38 |
Linkki tähän viestiin
|
|
Nuo moodit muuttuivat tuossa DivX:ssä se nykyinen Insane on todellakin Insane, eikä sen käyttö juuri kannata muutenkaan. Mutta ei sen silti pitäisi viikkoja viedä ja tuo first passin jumiutuminen on joko bugi codecissa tai softassa.
|
|
Titan
Junior Member
|
17. heinäkuuta 2006 @ 11:42 |
Linkki tähän viestiin
|
|
Mitään ihmeempiä filttereitä ei ole, vain crop ja resize.
1 passiin meni näköjään aikaa 10h 46min. Xvidillä homma menee alle kahdessa tunnissa yleensä :)
Nyt menossa 2. pass, jossain vaiheessa iltaa valmis. Parin vuorokauden homma...
Taidan siirtyä Xvidin käyttäjäksi.. :p
|
|
Titan
Junior Member
|
18. heinäkuuta 2006 @ 14:34 |
Linkki tähän viestiin
|
|
Kyselin asiasta DivX:n foorumeilta ja tein pari testiä eri menetelmillä ja tässä olis tuloksia (1min dvd clippi, ei ääniä ja vakio avisynth scriptit. 2passina vedin tietenkin):
Divx: Q-pix: disabled, GMC: disabled, Encoding mode: BALANCED, quantization: h.263 optimized => 1min 35s
Divx: Q-pix: disabled, GMC: disabled, Encoding mode: INSANE, quantization: h.263 optimized => 3min 40s
Divx: Q-pix: enabled, GMC: enabled, Encoding mode: INSANE, quantization: h.263 optimized => 11min 40s !!! :)
Xvid: Q-pix: enabled, GMC: enabled, motion search: ultra high, VHQ mode: wide search
=>2min 56s
Sellasta...Xvidillä sai melkeinpä parasta laatua tällä kertaa.
|
|
Titan
Junior Member
|
18. heinäkuuta 2006 @ 15:06 |
Linkki tähän viestiin
|
En viitsinyt uutta ketjua tehdä joten muokkasin otsikkoa ja ajattelin kysäistä asiasta täältä.
Nyt tässä sekoillessa hitaan rippauksen kanssa tuli eteen aivan uudentyyppinen ongelma. Käsittelemäni DVD on Progressive tyyppinen joten ajattelin että nyt päästään helpolla.
Ennen oli ongelmia sellaisten pätkin kanssa jotka olivat hybridejä....eli löytyi sekä progressive että interlaced kamaa samasta pätkästä. Apu ongelmaan löytyi decomp plug-inistä kun käytti FieldDeinterlace(full=false) jolloin ainakin manuaalin mukaan vain havaitut lomitetut pätkät käsitellään.
Mutta nyt on DVD jonka bitrate viewerkin näyttää ihan puhtaaksi progressive tapaukseksi mutta rippauksen tulos osoittaa jotain ihan muuta. Liikettä sisältävät pätkät ovat kehnoja, "haamukuvia" ja "häntimistä" esiintyy.
Selasin sitten Decompin manuaalia ja löysin tälläisen jutun:
"Progressive frame Recovery: If you have telecined film (progressive) source and want to recover the progressive frames but not change the frame rate by decimating, you proceed as follows:
LoadPlugin("decomb.dll")
AVISource("film.avi")
Telecide(order=1)"
Tein testipätkän annetuilla arvoilla ja heti näytti paremmalta. Mutta voisiko joku kertoa mitä itseasiassa tuo "telecide" tekee? En oikein ymmärrä koko juttua...
Sitten manuaali sanoo:"Use order=0 for bottom field first (bff). Use order=1 for top field first (tff)"
Mistähän tietää kumpaa pitää käyttää mikäli tämä toiminto on ylipäätään oikea tähän tilanteeseen?
|
Staff Member
32 tuotearviota
|
18. heinäkuuta 2006 @ 16:26 |
Linkki tähän viestiin
|
|
|
Senior Member
|
18. heinäkuuta 2006 @ 16:42 |
Linkki tähän viestiin
|
Telecine, joka myös tunnetaan nimellä 3:2 pulldown on meneltemä, jolla voidaan progressiivisesta FILM materiaalista (23,976 FPS) tehdä NTSC-standardin mukainen. Eli jokainen kuva (frame) jaetaan kahteen kenttään (field), joita sitten toistetaan 2:3-suhteessa. Eli ensimmäistä FILM-videon kuvaa vastaa NTSC:n kaksi kenttää, seuraavaa FILM-videon kuvaa vastaa taas kolme NTSC:n kenttää, seuraavaa FILM-videon kuvaa vastaa kaksi kenttää, ja niin edelleen.
TFF ja BFF tarkoittavat kentän juovajärjestystä, eli TFF tarkoitta "Top Field First" ja BFF tarkoittaa "Bottom Field First". Decombin manuaalissa kyllä kerrotaan kuinka BFF:n ja TFF:n voi erottaa toisistaan. Suurin osa videoista, mitä olen itse käsitellyt ovat olleet TFF. Tosin kaikki DV-videot ovat taasen BFF.
http://en.wikipedia.org/wiki/Telecine
http://www.doom9.org/index.html?/synch.htm
Viestiä on muokattu lähettämisen jälkeen. Viimeisin muokkaus 18. heinäkuuta 2006 @ 20:12
|
|
Titan
Junior Member
|
18. heinäkuuta 2006 @ 17:56 |
Linkki tähän viestiin
|
Örrr..siis katotaas nyt...
Siis minkähänlaista materiaalia tää mun DVD nyt itseasiassa on...
Se ei ole lomitettu ilmeisesti koska kokeilin juuri fieldDeinterlacea ja haamukuvia riittää.
Bitrateviewer kertoo seuraavaa VOB:eista:
Stream type: MPEG-2 MP@ML CBR
Resolution: 720*576
Aspect ratio: 16:9 Generic
Framerate: 25.00
Nom. bitrate: 6000000 Bit/Sec
VBV buffer size: 112
Constrained param. flag: No
Chroma format: 4:2:0
DCT precision: 8
Pic. structure: frame
Field topfirst: No
DCT type: frame
Quantscale: Nonlinear
Scan type: ZigZag
frame type: Progressive
Gspot informoi vobeista että ne on:
PAL
Frms/s 25
Flds/s 50
TFF
Öh, siis ilmeisesti flds/s on lyhenne Fields per second. 50 sekunnissa, pitäiskö tästä päätellä että lähde on sittenkin lomitettu? :) Ja Top Filed First...hmm ei oikein aunnut noi englanninkieliset tekniset dokumentit joten jäi vähän epäselväksi että mihin toimenpiteisiin sen seurauksena pitää ryhtyä.
Mutta siis miten ihmeessä kuvasta tuli heti parempi kun käytti decompin Telecide:ä jos se kerta on tarkoitettu, kuten tuo sanasto ilmaisee:"...eli poistaa lisätyt framet jolloin framerate muuttuu NTSC-television käyttämästä 29.97 fps lukemasta 24 fps lukemaan." (http://fin.afterdawn.com/sanasto/termit/inverse_telecine.cfm)
Eihän tässä mitään NTSC tavaraa käsitellä, silti haamukuvat häipyy. Tosin vaikutaa siltä että ihan alkuperäistä vastaavaan tulokseen ei päästä. Oon kyllä aivan sekaisin pikkuhiljaa...
|
Senior Member
|
18. heinäkuuta 2006 @ 19:27 |
Linkki tähän viestiin
|
Vaikkei varsinaisesti ole kyse NTSC materiaalista, niin se ei tarkoita, sitä etteikö siinä voisi olla NTSC:n piirteitä. Jotkut halvat DVD:t on tehty ensin NTSC:ksi, jonka jälkeen ne on pakattu vielä PAL-standardin mukaiseksi. Eli videossa voi olla täten myös NTSC:n piirteitä, ikävä kyllä. Tällaisten käsitteleminen on yleensä erittäin vaikeaa, eikä "hyvää" lopputulosta saa aikaan kovinkaan monesti.
Video on vieläpä enkoodattu käyttämällä progressiivisen kuvan asetuksia, joten sekin kielii halvasta masteroinnista.
Quote:
Öh, siis ilmeisesti flds/s on lyhenne Fields per second. 50 sekunnissa, pitäiskö tästä päätellä että lähde on sittenkin lomitettu? :)
Kyllä. Tuo vastaa PAL-standardia. Yleensä lomitelluille PAL-videoille riittää FieldDeinterlace, mutta tuo videosi vaikuttaa aika mutkikkaalta.
Jos mahdollista, niin leikkaa muutaman minuutin pätkä siitä videosta ja laita se jakoon jonnekin. Olisi ihan mielenkiintoista tutkia videota, ja koittaa vaikka väsätä jotain scriptiä.
Viestiä on muokattu lähettämisen jälkeen. Viimeisin muokkaus 18. heinäkuuta 2006 @ 19:28
|
|
Titan
Junior Member
|
19. heinäkuuta 2006 @ 12:45 |
Linkki tähän viestiin
|
|
|
Senior Member
|
19. heinäkuuta 2006 @ 18:18 |
Linkki tähän viestiin
|
|
Onko tuo "muokkaamaton" todella muokkaamaton, se ei nimittäin näytä juurikaan siltä? Mutta eipä sillä ole niin merkitystä, noista kuvakaappauksista ei voi sanoa juuta eikä jaata. Se muokkaamaton videopätkä olisi kyllä loistojuttu.
Viestiä on muokattu lähettämisen jälkeen. Viimeisin muokkaus 19. heinäkuuta 2006 @ 18:19
|
|
Mainos
|
|
|
|
Titan
Junior Member
|
19. heinäkuuta 2006 @ 18:39 |
Linkki tähän viestiin
|
|
Ensimmäisen linkin kuva on toistoa suoraan VOB:ista bsplayerillä. Kuvasuhde vain on tällöin väärä...
Ja en ole vielä kekkassut mihin voisin pistää jakoon videota ikävä kyllä :/
Noh, sain kuitenkin tyydyttävää jälkeä aikaiseksi tuolla telecidellä vaikka en aivan tajunnut mitä olen edes tekemässä :)
|
