Fórumok
a cím magáért beszél: lehetséges az, hogy mplayer-t több maggal rendelkező cpu-n úgy futtassunk, hogy az ebben rejlő lehetőséget ki is használja? a problémám az lenne, hogy van egy 1080p-s hd filmem, ami meglehetősen szaggat egy 2ghz-es 2magvas turion64-en, de szerintem ha a két magban rejlő lehetőségeket kihasználná a lejátszó akkor ez a probléma nem állna fenn!
valaki tud erről esetleg valamit?
Hozzászólások
Direct rendert allitsd be, ha nincs eddig.
Futtasd a -dr opcioval.
Videokimenetnek xv-t hasznalj (-vo xv).
Ja, nem a proci a betegsége. Esetleg még -vo gl, -vo gl2 opciókkal is próbálkozhatsz, de mindenek előtt
mplayer -vo help
Na, ekkor kiderül, milyen lehetőségeid vannak.
mplayer -sws 0 -mc 0 -vfm ffmpeg -lavdopts lowres=1:fast:skiploopfilter=all -cache 16384 ...
El kellene olvasni mit ir ki az a software mikor nem tudja elegendo sebesseggel dekodolni a filmet.
Amugy a kerdesedre a valasz nem. Jelenleg erre csak closed source codec-ek kepesek, azok is csak x264-nel, es megfeleloen kodolt filmnel. Nezz utana a geped beallitasainak, mert ilyen kaliberu filmek nekem 1.83-as CD-n mplayer-rel siman mennek ugy, hogy meg kanasztazni is raer a processzor. Mondjuk nem linux alatt, az is igaz.
---
pontscho / fresh!mindworkz
De, mar lehet ilyet. lavdopts-ban threads=2 , forrastol fuggoen mukodik, ha a "fast"-ot is megadod a lavdopts-ban akkor meg valoszinubb, hogy mukodik. Ehhez egy eleg uj libavcodec kell.
Amugy a coreavc (a close source codec amirol beszelsz) az allitolag nem olyan valogatos, nem annyira (vagy egyaltalan nem?) fugg a forrastol, hogy tudja-e tobbszalon dekodolni. Libavcodec-nel viszont fugg par dologtol (legyen ket slice legalabb, es ha nincs bekapcsolva a "fast" akkor nem szabad valamilyen loopfiltert hasznalnia a forrasnak).
- Use the Source Luke ! -
De, mar lehet ilyet. lavdopts-ban threads=2 , forrastol fuggoen mukodik, ha a "fast"-ot is megadod a lavdopts-ban akkor meg valoszinubb, hogy mukodik. Ehhez egy eleg uj libavcodec kell.
Ez mar egy masik szalban ki lett vesezve, spec kodolasnal van szerepe csak, de mivel ez tobb helyet igenyel nem hasznaljak. Cserebe utana neztem ennek a lavc thread dolognak, eddig inkabb lassitott vagy semmit nem szamitott, mint javitott a helyzeten. :)
Amugy a coreavc (a close source codec amirol beszelsz) az allitolag nem olyan valogatos, nem annyira (vagy egyaltalan nem?) fugg a forrastol, hogy tudja-e tobbszalon dekodolni.
:) Tudom. viszont csak w32-re van, ott pedig rendes videokartyaval a PureVideo (es tarsai) ext is hasznalatban van, igy oda meg kevesebb CPU kell a dekodolashoz.
---
pontscho / fresh!mindworkz
egyenlőre sajnos csak vindóz alatt tudom mplayer gui-val tesztelni (rc1-es van még csak elérhető formában kint) remélem nemsokára linuxos gépem is össze tudom majd állítani aztán azon is letesztelem ...
Min. Req. RC2.
---
pontscho / fresh!mindworkz
helló!
na sikerült letöltenem egy nem hivatalos forrásból vinfos alá mplayer console-os lejátszót innen: http://data.netfast.org/downloadse.html, ez már 1.0-rc2 -es verzió, 4.2.2-es gcc-vel forgatva.
megnéztem a kimenetet és itt is akadozik, amire rájöttem, hogy a-v sync az kiesik és ezután elkezd beszaggatni, -nosound opcióval gond nélkül lejátsza!
Nincs eleg kraft a gepben. Vagy lefogja valami a hatterben, vagy valoban ennyire kepes W32 alatt.
---
pontscho / fresh!mindworkz
nojó, de az audió lefogja teljesen, miközben kb. 40% a proc használat (nosound-dal, azaz audió nélkül)a 1080p-s videoval? érdekesnek tűnik.
te macán hasnyálod az mplayert egyébiránt?
Esetleg a hangkartya driver fos?
te macán hasnyálod az mplayert egyébiránt?
Igen.
---
pontscho / fresh!mindworkz
http://mplayerxp.sourceforge.net/
hű de jó, még egy mplayer fork. nem lehetne inkább az mplayert fejleszteni tovább?:)
::sumo.conf::