[kaliif]

millest sõltub konvertimise kiirus virtualdubis ja premieres jne.
mul on fps kuidagi madal konvertimise ajal- võtab kuidagi liialt kaua aega.

[Ho Ho]

prose, mäu ja kettaseadmed. Muidugi oleneb mis algoritmiga ning kvaliteediga konvertida

[bjand]

oleneb ka mis tehnikat mingi prose kasutab. näiteks üks proge, nime ei mäleta, pakkis mul amd 700 sama kiiresti kui p4 2,8ga. mõni proge bufferdab kettale pakkimata avi juppe ja siis pakib millegiks muuks, enamus pakib otse. sel juhul ikka prose jõudlus, mälu ja kettad nagu eelpool oligi öeldud.
muidugi see ka, et iga efekt või vidin mis sa määrad oma ümberpakitavale asjale tõmbab järjest väiksemaks fpsi.

[kaliif]

mul 3g prescot ja 160g sataraid eraldi video jaoks ja 1g RAM
prose kiirus konvertimise ajal aint 50%

[bjand]

kui sa prose kasutusressurssi vaatad, siis peaksid proovima kuidagi "priority" t muuta ... näiteks kas siis taskmanageri alt saad seda näppida konkreetsel protsessil või annab proges seda muuta.
aga ega sa eriti sellega ei võida. oluliselt ma mõtlen. lihtsalt teeb sul 10% võibolla kiiremini aga samas on masin koomas. mulle näiteks meeldib vahest uudiseid lugeda kui midagi pakib. kui sa priorityd highks paned siis see eriti ei õnnestu enam. see 50% on see ma eeldan, et kuna sul HT prose.
pakkimise kiirust see ei näita. pakkimise kiirust on parem vaata per real time. ehk kui sul on 1 tunni video siis kui kaua kulub selle asja pakkimiseks. kui 2h siis on 1:2.
no mul on 2,8persskott ja 500 rami et kui ma mpegi dv aviks pakin siis mul läheb suht 1:1. kui ma avi peale lõikumist jälle mpegiks panen siis läheb ala 0,90 real time.
kui mpegi pakkides panna jällegi mingi efekt lisaks, siis kukub see kohe 0,5RT peale.

[kaliif]

ma tahaks et arvuti konvertimise ajal ainult konverdiks ja kasutaks kogu prose võimsust ära
kas seda on võimalik saavutada kuidagi (prose on HT)

[bjand]

üks variant on siis proges otsida setingutest comperssion "priority" kui on.
Teine: võta run-> taskmgr -> | processes | leiad sealt protsessi, mis sul siis konkreetselt pakkima hakkab -> parema hiire klahviga võtad protsessi peal lahti menüü, kus valid "set priority" paned High.
Realtime võid ka panna aga ma ei tea, kas paneb pange masin. "Set affinity" alt võid kontrollida kas kasutatakse mõlemat HT poolt.

[kaliif]

ikka on 50%
realtime toimib ilusti, kuid ikkagi on 50%

[bjand]

viga võib ikka proges endas olla. s.t. näiteks ei oska ta HT ära kasutada. võibolla mõni update , plugin seda ma ei tea - google aitax kindlasti.

[kaliif]

kas keegi teab kust saaks virtualdubmod-i jaoks HT-enable plugini
otsisin pikalt googlist kuid ei leidnud midagi

[suur13]

Ketta kiirus nüüd küll väga ei mõjuta.
Ja kui mälu on üle 256MB, siis see ka vast mitte väga.

Mina paneks tegurite listi paika nii:

1. Kasutatavd filtrid (igast mürafiltrid jne. võtavad kiirust alla KORDADES).
2. Prose kiirus (puhas megaherts loeb, vahemälu mitte väga).
3. Koodek (näiteks on XviD ligi 2 korda kiirem kui DivX).

[bjand]

katsetasin veidi. tegin mpegist -> avi

võta options -> perfomance -> avi output buffering -> lükka lõppu
tegelt kõik buffrid võid lõppu lükata.
siis options-> preferences -> main tab -> prosess priority -> pane mõlemad highest

kui paned "save avi", võta maha preview for input ja outputi jaoks.
25 sek 720x576 mpeg2 oli siis input.

test1: output codec uncompressed avi. kiirus 40fps. Mis on väga norm tulemus. fail tuleb suur. mul siis 0,8gb test failiga.
test2: output codec canopus soft dv. kiirus 28fps. output size tuli 80mb.
test3: output codec canopus hardware dv. kiirus 32fps. output size tuli 80mb.
test4: output codec xvid default settingutega 1pass. kiirus 24fps. output size tuli 3mb.
test5: output codec mpeg4 m$ v2 default settingutega fr 3kbs. kiirus 34fps. output size tuli 10mb.

ühtegi filtrit ei kasutanud.
huvitav on see, et avist avi tehes oli perfomance kõvva sitem. võimalik, sest kasutan ise virtualdub-mpeg2 1.5.10t

[suur13]

[bjand]

parandasn just eelmist posti

[bjand]

proovin ka üht teist programmi, nimelt siis canopus procoderit mis oli mul canopuse kaardiga kaasas, see oskas kasutada lõdvalt 98% prosest. näitas et teeb sama asja 34fps'iga uncompressed avi puhul.
ehk siis eelmises testis tehtud mpeg2 -> aviks.

ehk siis mingit olulist vahet ei olnud kas dub kasutab 50% prosest või canopus 98% prosest. kiirus tuleb suht sama.
ega ma normaalse tavakasutuse puhul üle 2x realtime pakkimist palju näinud ei ole. 60fps on maksimum mis ma saanud olen töö tegemise puhul.
s.t. ma ei benchi ega forsi midagi - lihtsalt võtad mingi video, paned näiteks brightnessi juurde või lõikad jupi maha jms. ehk tehes tavalisi asju. ja niikaua kui asi teeb 25fpsist asja 25fpsiga on asi rahuldav. mis üle selle on hea. kui saad realtimest 2 korda kiiremini on väga hea.

oleneb jah mida teed. on olemas ju ka näiteks mpegi restruktueerijaid kui see oleks õige sõna -> et ei pakita midagi ümber, vaid failis sisalduv inf moditakse ära. sellisel juhul on ainult ketta kiiruses asi kinni.

[kaliif]

canopus procoder- mis selle proge õige nimi on

[bjand]

see ongi õige nimi aga see on ostes väga kallis aga peaks vist trial ka olema kuskil ... procoder express on ka olemas. nagu ka procoder 2.

[suur13]

OK, tegin ka loomkatse.

Arvuti konf on profiilis, op.sys. on XP sp2. Kasutasin VirtualDub 1.4.13-MPEG2'te
ja ffmpeg version 0.4.9-pre1, build 4723.
Clean boot. Mälu kasutus 70MB.

Klipp "Vanilla Ninja - Tough Enough.m2v"
Pikkus 3:20 (200 sec.). FPS - 25. 480x576. Progressive scan (DVD Rip).
Video siis MPEG2 2704 kbps, audio mp2 224 kbps.

Paari esimest proovisin koos ja ilma preview for input ja outputita.
Samuti koos ja ilma DirectDraw Accelerationita.
Ja koos ja ilma audio streamita (kui oli koos, siis tegin Direct Stream Copy).
Ühesõnaga audiot ei pakkinud.

Kõik need eelnevad kolm lisaoptsiooni kogu protsessi kiirust ei mõjutanud !
Kui siis natuke (1 või 2 sekundit selle loo kohta max.)

Niisiis.

1. Fast Recompress ja Uncompressed RGB.

Protsess võttis aega 8 min. ja keskmine FPS oli 11
Data kettale kirjutamise rate oli rohkem kui 20 MB/s.
Niiet selliste andmemahtude juures mängib ikka kõvaketta kiirus rolli küll...
Faili suurus tuli üle 4 GB.

2. Fast Recompress ja Xvid 1.0.2

Bitrate'iks panin 1600 kbps. Siuke harju keskmine.
Aega võttis 2.19 ja FPS 36 siis. Kettale kirjutamise kiirus umbes 400 KB/s (koos audioga).

3. Full Processing Mode ja Xvid 1.0.2

Croppisin video ära ja vähendasin suurust 384x288 peale. Bitrate 1600 kbps.
Aeg 2.01 ja FPS 42. Väiksem pilt, vähem tööd pakkimisel. Musti ääri ka polnud enam.

4. Full Processing Mode ja Xvid 1.0.2

Lisasin Sharpen filtri. Aeg 2.07 ja FPS 39. Niiet vähemalt see filter ei mõjutanud sittagi.
Ja ega ka lõpptulemusel suurt vahet ei olnud.

5. Fast Recompress ja Xvid 1.0.2

Vähendasin bitrate'i poole võrra. 800 kbps.
Aeg 2.10 ja FPS 38. Niiet väiksem bitrate veidi mõjus.
Ja ega ka tulemus palju kehvem polnud kui 1600 kbps puhul...

6. VD kinni ja kolm viimast raundi ffmpeg'ga.

Mingit processingut ei teinud ja bitrate 1600. Ilma audio-streamita.

35 freakin' sekundit . FPS - 143.

7. Sama, aga bitrate 800 kbps.

29 sek.

8. Bitrate 1600 kbps, KOOS audio ringipakkimisega -> 64 Kbps peale.

40 sekundit


Kvaliteet oli 800kbps juures vähe kehvem kui XviD (mis on vast kvaliteetseim koodek).
1600 juures polnud enam mingit vahet minu silmis.

[HacaX]

Omaette küsimus miks Task Manageriga mässata kui VirtualDubil on konvertimise aknas ilusasti olemas võimalus prioriteeti määrata

PS! FFMPEG ju kasutabki oma kodeerimiskoodi (seesama mida tarbib MPlayer ja FFDSHOW) mis ongi kiirem. VirtualDub IMO läheb ikka läbi masinasse installitud filtrite, seega saab aegluse kanda XVIDi arvele.

[bjand]

nii on.
seda taskmanageri ma pakkusin juhuks kui proges seda määrata ei saa ...

[suur13]

No seda ma näitasingi, et väga palju oleneb koodekist.

ffmpeg (tegelt siis libavcodec) vs. XviD.

DivX on veel aeglasem.

[kaliif]

on järsku mingi driver xp jaoks mis paneks mõlemad prosed tööle- mingi HT akkseleraator või midagi taolist

[Ho Ho]

see kui ei kasutata korraga mitut (virtuaal) proset on ikka programmi viga. Ainus lahendus on otsida uuem/parem programm

[bjand]

nii on - midagi pole teha ...