Fórumok
Compaq D530 SFF
P4, 2.4GHz (512KB L2)
512MB (2x256) DDR1 RAM
NV11 Geforce 2 MX200 64MB AGP4X VGA
40 GB IDE HDD
konfigon a cikkben megadott szoftver összeállításban
1920x1080 mkv (h264) film, teljes felbontásban,
mindössze a skiploopfilter opcióval
97-100% CPU terhelés mellett lejátszható.
(a hang néha akadozott, de az oka nem alsa,
hanem a 4x AGP VGA -mint szűk keresztmetszet- volt.
Ki fogom próbálni "újabb" VGA kártyával...)
Hozzászólások
És? :)
Egyébként mkv és mkv között hatalmas a különbség..
Ez a konfig sok szempontból kevés hozzá.
én 3 ghz-es 2 magos celeron-on próbáltam 1szer és azon eléggé akadt...
Dropbox:
https://www.getdropbox.com/referrals/NTI3NzY1ODQ5
Keresgélem a határértéket, amit számításokkal és tapasztalatból már nagyjából sikerült beskálázni,
nagyjából 2,5GHz CPU környékére, de az eltérő cache méretek miatt nagyobb szórást becsültem, mint ami lett.
Nem létezhet, hogy ebben az esetben ennyire mindegy legyen a gyorsítótár mérete és megoldása.
Ez már felvetheti a fordítóprogram minőségének kérdését is.
Lehet, hogy rosszul gazdálkodik a cache-sal?
-
"Attempting to crack SpeedLock can damage your sanity"
az ilyen stream jellegu cuccok (folyamatot olvasol/irsz) elegge cache fuggetlenek. Persze, a kitomoriteseknek mindig van valami kuszoberteke, ami alatti cache eseten extrem rosszul viselkedik, de afeletti meret eseten mar mindegy.
Ez elég érdekes, mert én legutóbb pont az Avatart néztem 1920-as mkv-be, és a c2d e8400 egyik magja csúcson pörgött 3Ghz-en, 90-95, terheléssel.
--
Discover It - Have a lot of fun!
"a hang néha akadozott, de az oka nem alsa,
hanem a 4x AGP VGA -mint szűk keresztmetszet- volt."
Ez nem igaz !!!!
Az általad átküldött adat mennyiség az AGP csatolón 198 Mbyte/sec.
AGP 4x esetén az átküldhető adat mennyiség 1066 Mbyte/sec.
Ez 5x nagyobb az általad megkívántnál.
Az AGP 1x is többet tud mint az elvárt.
Egy hasonló konfig ,ha nem AC3/AAC/DTS hang van alatta
akkor pont a határon egyensúlyozik.
A hang akadozás oka ,hogy a master streaming az a videó sáv és ahoz szinkronizál.
Amennyiben a hanghoz szinkronizálnál akkor a kép akadna.
Próbáld olyan filmel ahol mp2/mp3 hang van alatta.
De, igaz, direct rendering nélkül.
A számításaid -mint elméleti sávszélesség az agp-re vonatkozóan- helytállóak,
de elmélet és konkrét VGA kártya és drivere közt óriási a különbség.
-ao null ill. -nosound paraméterrel ellenőriztem. :)
-
"Attempting to crack SpeedLock can damage your sanity"
"de elmélet és konkrét VGA kártya és drivere közt óriási a különbség"
A legnagyobb átküldhető adatmenyyiség ami a lehet,
a driverben beállítható legnagyobb felbontás szor legnagyobb frissítés.
Már ha a monitor tudja.
"De, igaz, direct rendering nélkül."
A DRI-nek ehez nincs köze.
A gyenge DRI implementálás és az AGP áteresztő képessége között nincs összefüggés.
Az AGPxx a fizikai réteg a DRI az adat kapcsolati réteg.
Tehát a hiba nem az , hogy a fizikai réteg a szűk keresztmetszet !!!!!!!!!!!
1. A RAMDAC sávszélességének semmi köze ahhoz, hogy a buszrendszer elméleti sávszélességéből
a periféria mennyit hasznosít adott esetben.
Ezen az alapon egy AGP-s S3 Savage kártyán is csodálatos átviteli értékeket kellene mérni.
Még jobb hasonlat az IDE UDMA, ahol a teoretikus átviteli érték nem azonos a lehetségessel.
2. NEM A DRI-ről volt szó, hanem az MPlayer direct render funkciójáról,
amikor memcopy-t spórol azzal, hogy közvetlenül a VGA memóriájába rendereli a képet.
(ha minden igaz, csak vidix esetén működik, xv-nél nem)
-
"Attempting to crack SpeedLock can damage your sanity"
"Ezen az alapon egy AGP-s S3 Savage kártyán is csodálatos átviteli értékeket kellene mérni."
Azt is fogsz ,az is AGP2x/AGP4x tehát többszöröse az elvártnak.
Csak a PCI csatolós kártya korlátozna.
"Még jobb hasonlat az IDE UDMA, ahol a teoretikus átviteli érték nem azonos a lehetségessel."
Ne ködösíts , olvass a drive bufferéből és látni fogod hogy igen közel van a max értékhez.
Lehet kapni PATA-s SSD-t ott is nagyon közeliek az értékek.
"NEM A DRI-ről volt szó, hanem az MPlayer direct render funkciójáról"
Mi is ez akkor valami overlay funkció ami a kártya driverében van megvalósítva ?
Mert akkor sincs köze a fizikai csatolóhoz !!!!!!
Akkor az inkább Xserver verziónként , kártyánként méginkább driverenként változik.
man mplayer
-dr
erről van szó, mármint arról, hogy enélkül ment a teszt.
-
"Attempting to crack SpeedLock can damage your sanity"
Helyes .
Akkor javítsd az első postodat , hogy nem az AGP4x csatoló hanem az agyon dícsért NVIDIA linux driver
a korlátozó tényező !
Világosan oda volt írva, hogy NV11.
Azaz Geforce 2 MX 200.
Azaz nvidia driver 96.43.
Kifejtsem bővebben, hogy hol van itt a szűk keresztmetszet,
1920x1080 32bit üzem esetén, vagy bízzuk a többiekre?
Konzolon man mplayer már sikerült?
A -dr miatt kérdezem csak...az a vidix-nél van, pl.
http://freshmeat.net/articles/fine-tuning-mplayer
"Direct Rendering" címszónál.
-
"Attempting to crack SpeedLock can damage your sanity"
"Kifejtsem bővebben, hogy hol van itt a szűk keresztmetszet,"
Nem kell már megtetted az első posztban, hogy szerinted a hardware fizikai csatoló a hibás.
Te irtad:
"(a hang néha akadozott, de az oka nem alsa,
hanem a 4x AGP VGA -mint szűk keresztmetszet- volt."
Én viszont arra birtam felhívni becses figyelmed , hogy a VGA lehet oka , de nem a csatolója miatt.
Ajánlom tanulmányozásra.
http://en.wikipedia.org/wiki/Accelerated_Graphics_Port
A hardware képességek pontosan definiáltak , hogy egy software (bughalmaz) ebből mit tud kihozni
az már más kérdés.
"Konzolon man mplayer már sikerült?"
Nem! Mi az a konzol mi az man és főleg mi az az mplayer ? :)
Nem! Mi az a konzol mi az man és főleg mi az az mplayer ? :)
A konzol pl. Sega is lehet, a MAN pedig egy teherautó-márka...:)
Szerintem guglizz rá, de nem a fenti kulcsszavakra,
hanem arra, hogy hol találsz a hup helyett
egy számodra alkalmas windows témájú fórumot...
Egyébként a GF2 MX200 kapcsán ajánlom figyelmedbe a következőket:
http://en.wikipedia.org/wiki/GeForce_2_Series
http://en.wikipedia.org/wiki/Synchronous_dynamic_random_access_memory
Itt kimerítően leírják, hogy az említett kártya 32-bites memória-szervezésű,
max. 166MHz-es sdram-mal szerelt (volt belőle ddr verzió, de a nálam lévő példány sd),
és a kártya memória-vezérlése még ezen túlmenően bőven nem tudja kihasználni
a 4x agp nyújtotta lehetőségeket, erős veszteséggel üzemel,
papíron és ideális esetben is csak a sávszélesség max. 1/2-2/3-át használhatja ki,
ez is erősen elméleti maximum-érték, semmilyen egyéb "bottleneck" nincs belekalkulálva.
A kártyához -mivel régi- a 96.43 a legutolsó nvidia driver, ez is korlátozó tényező.
Fentiektől függetlenül kíváncsi voltam, hogy mit lehet belőle kihozni.
-
"Attempting to crack SpeedLock can damage your sanity"
"papíron és ideális esetben is csak a sávszélesség max. 1/2-2/3-át használhatja ki,
ez is erősen elméleti maximum-érték, semmilyen egyéb "bottleneck" nincs belekalkulálva."
Ez is még bőven több mint amit te szeretnél!!!!!
Ugyan ilyen beteg kártya egy 3.2GHz P4 processzorral már nem akadozik , csak durva bitrátáju filmeknél.
Egy kétmagos 2.4GHz AMD procival VIA-s alaplapban pedig egyáltalán nem akad.
Nekem is van próbáltam egy EIZO 21" monitoron.
Tehát a csatoló továbbra sem probléma.
A szűk keresztmetszet a processzor !
Egyéb iránt az mplayer manualja erre nézve semminemü infóval nem szolgál.
"hogy hol találsz a hup helyett
egy számodra alkalmas windows témájú fórumot"
Miért ott a hardwarekről nem irogatnak valótlan dolgokat ,és nem ajálngatják ,hogy
hogyan mplayerjük manban a konzolt ? :)
Lehet ezt neked kéne megfontolnod ,ott nagyobb igény van az OS/mediaplayer tuningolására.
Az mplayer manualja arra vonatkozólag ad infót, hogy a -dr opció,
azaz direct rendering mit jelent pl. a vidix kimenetnél.
Simán összekeverted a DRI-vel, ezért alakult ki ez a vita.
A GF2 MX200 esete még egyszer: az AGP 4X sávszélesség 1066MB/s, de
a fenti kártya -SDRAM és az adott memória-vezérlő okán- mindössze
532-664MB közötti maximumra képes, arra is csak elméletben.
1920x1080 HD filmnél 1920x1440 üzemmód kell.
1920x1440x4x24=~253MB/s (felbontás x színmélység x 24 fps esetén).
Ez eddig teljesen oké lenne.
Amit nem számoltál bele, az az, hogy a RAMDAC ugyanazt a memóriát
olvassa legalább 60-szor másodpercenként, az
1920x1440x4x60=~633MB/s,
és a két eredményt össze kell adni...
253+633=886MB/s adatmozgás (írás/olvasás) a VGA memóriájában.
Ennyit nem tud a GF2 MX200 memóriája, csak 25-40%-kal kevesebbet.
-
"Attempting to crack SpeedLock can damage your sanity"
"és a két eredményt össze kell adni...
253+633=886MB/s adatmozgás (írás/olvasás) a VGA memóriájában."
Ne add össze mert a kártya tud side band addressinget és fast write-ot is.
Igy kellene elvileg Linux alá beállítani.
http://www.mythtv.org/wiki/Nvidia_Driver_AGP_Fast Write_and_Side_Band_Addressing
Nekem az AMD-s configba nem sikerült beállítani a fast write-ot mégis az teljesített jobban.
Teljesen mindegy.
Azonos memóriacímen, egy időben, csak egy műveletet tudsz végezni.
Az alkalmazott memória sebessége, és szervezésének,
vezérlésének módja által adott fizikai korlátok alól
nem tudsz kibújni semmivel sem.
A fentieket (fast write, sba) a kártya AGP-illesztő áramkörei tudják.
A 32-bites szervezésű és max.166MHz-en ketyegő sdram
egyazon címtartománya nem képes kb. 664MB/s fölött teljesíteni.
Az egyetlen járható út ebben az esetben az lenne,
ha a videódekóder szoftver csak a változásokat küldené
a kártya memóriájába, a nem változó makroblokkokat pedig nem.
Ezzel meg lehetne spórolni a terhelés felét-harmadát,
így már elbírná.
(nem új az ötlet, -javíts ki ha rosszul tudom- de talán így üzemel a CoreAVC is,
és rémlik, hogy vidix doksiban is olvastam ilyet)
-
"Attempting to crack SpeedLock can damage your sanity"
"Azonos memóriacímen, egy időben, csak egy műveletet tudsz végezni"
Ez igaz , de nem feltétlenül ugya azt a blokkot írja , amit a RAMDAC olvas.
Ezért van az a jelenség bizonyos ATI 9500 kártyákon ,hogy ha bekapcsolod a fast write-ot és szétesik a kép.
Nincs prioritása a RAMDAC-nak , így nem tud szinkronban maradni a kép.
(Később javították VGA BIOS frissitéssel.)
"(a hang néha akadozott, de az oka nem alsa,
hanem a 4x AGP VGA -mint szűk keresztmetszet- volt."
Akkor ezek után kijelenthetjük , hogy nem az AGP4x volt a szűk keresztmetszet hanem
az NVIDIA kártya gyatra memória szervezése.(lassú sdram)
Fontos ezt kijelenteni mielőtt valakiben az maradna meg ,hogy AGP8x alatt nem is lehet HDvideót lejátszani !
Ennek ellenére lényegesen erősebb CPU-val ugyan ez a kártya látható framedrop nélkül
képes ugyan azt a videót lejátszani.
Ezért irtam az első posztomban , hogy az általad választott konfig pont a határon van !
(CPU is VGA is)
"nem új az ötlet, -javíts ki ha rosszul tudom- de talán így üzemel a CoreAVC is,
és rémlik, hogy vidix doksiban is olvastam ilyet)"
Valóban nem új , a csak Delta átküldése, emlékeim szerint az ASUS ASV1 tudta elször a RIVA128 kártyákon.
Mára sok codec tudja.(ON VP,Sorenson,CoreAVC is.
Pontosan, az adott kártya (GF2 MX200) egy olcsó, low-end típus volt,
memóriaszervezési kínokkal és szánalmas AGP hatásfokkal terhelve.
Konkrét VGA típusra írtam, amit írtam, és nem általánosságban.
A kártya RAM-ja (64MB esetén) 4 chip, per chip 4 bank x 1mbit x 16,
szóval 2MB szegmenseket lehetne külön kezelni a framebufferben,
ami 1920*1440*32bit esetén minden bizonnyal 16MB méretű lehet.
(azért csak lehetne, mert a memória-szervezése 32bites,
így viszont minden bank dupla, 4MB kellene hogy legyen)
Kérdés, hogy a 24fps írás, és a 60-75Hz olvasás
(egyik oldalról a cpu, másikról a ramdac)
milyen cpu teljesítmény mellett szinkronizálható
az adott sebességű 2-4MB bankokra akadás-mentesen.
Ki fogom próbálni egyazon gépet újabb v. gyorsabb vga-val,
de nem lesz egyszerű, mert low profile kell hozzá...(SFF gépház)
-
"Attempting to crack SpeedLock can damage your sanity"
A sávszélesség veszteséget amit a RAMDAC okoz ki lehetne mérni.
Ez viszont nagyon függ a RAMDAC tipusától , regiszterek száma/belső puffer szélességétől.
Az NVIDIA-n nemtudom mi az integrált RAMDAC , de itt van egy teljesen általános típus.
http://www.datasheetarchive.com/datasheet-pdf/018/DSA00320650.html
Meg lehet nézni , hogy milyen trükkökel óvják a sávszlességet.
No , de ezt már nagyon kiveséztük , a többséget meg nem érdeklik a technikai részletek ,
csak az ,hogy akadás mentesen tudjon lejátszani minden videót.
További jó tunngolást és fogyókúrát.
Azért még megmanom mplayerben a konzolt. :):)
A konkrét RAMDAC típus itt mindegy, meg is mondom, miért.
1920x1440 felbontásnál 166MHz-en 32bit szélességgel kell olvasni a RAM-ból.
(1920x1440=165888000, a szinkronidőket nem számoltam, de attól csak felfelé kell kerekíteni)
Az adott VGA memóriája 32bit széles szervezésű, és 166MHz-es. A kör bezárul.
(Ezzel megoldódott a -vo null "rejtélye" is.)
A tuning és a fogyókúra viszont megy tovább!
-
"Attempting to crack SpeedLock can damage your sanity"
"Itt kimerítően leírják, hogy az említett kártya 32-bites memória-szervezésű,"
Na ezt pontosan hol is olvastad ki belőle?
Később írod is hogy 4db chip van a kártyádon, s ha azok 16bitesek, máris 64bites kártyáról beszélünk. Persze az is lehet hogy 32bites chipekkel van szerelve, akkor már 128bites a memóriabusz szélessége.
Az adott kártyán a memória 32bit széles, 2x16bit szélességű sdramokból.
(HY57V641620HG, 4x1Mx16)
-
"Attempting to crack SpeedLock can damage your sanity"
Tehát 16 bites chipekből áll, egy chip 8MB... a kártya összmemóriája 64MB, szóval ez alapján 8db chip van rajta. Te 4db chipet írtál, de gondolom a kártya mindkét oldalán van 4-4.
Ebből következik, hogy a teljes szélesség 128bit.
Nem sorosan, hanem párhuzamosan szervezik a memória adatszélességét szerintem. Nem véletlen, hogy ugyanazon a nyákra épülő kártyákból a dupla memória chip szám dupla memória mérettel és dupla sávszélességgel párosul.
Egy 32 bites, 16MB-os kártya valahogy így néz ki:
http://www.dealtime.com/xPF-Compaq-nVidia-16MB-MX200-Gforce2-AGP-VGA-Ca…
De nézd csak az nvidia táblázatát:
http://www.nvidia.com/page/geforce2mx.html
Holnap találkozom a fent nevezett géppel, ha időm lesz rá, fel fogom nyitni a "motorháztetőt", és megszámolom a ramokat még egyszer...
nem állítottam soha, hogy tévedhetetlen lennék. Lekérdezem neked a pci azonosítót is, és abba fogjuk hagyni ezt az egészet,
ha igazam van, ha nem. Már régen nem arról írunk, amiért a topic létrejött.
-
"Attempting to crack SpeedLock can damage your sanity"
"Már régen nem arról írunk, amiért a topic létrejött."
szerinted a vga szűk keresztmetszet, mert szerinted 32bites a ramja... 64MB-os kártya esetén ez a lehetetlennel határos... téves megállapítás, félrevezethet másokat. Ezért nem hagyom rád, hogy ilyesmit terjessz.
Amit belinkeltél az nVidia oldaláról, az az ajánlott gyári specifikáció, magához a chiphez.
Az 1,3GB sávszélesség 166MHz ramoknál, 64bites szervezés esetén teljesül.
Konkrét gyártók nagyon eltérő kártyákat építettek köré.
Az adott példány egészen pontosan egy MSI kártya, low profile,
nv11 mag, GF2 MX200 rev. b2, BIOS 03.11.01.48.51,
az nvidia driver pedig ősrégi 96.43, mivel ezek újabbal már nem mennek.
A RAM 4 chip, (hátoldal üres) 16bit széles SDRAM modulokból, legjobb tudásom szerint is kettesével,
azaz 32 bit szélességben szervezve, és az órajele 143MHz.
143MHZ és 32bit szélesség az 572MB/s sávszélesség,
tehát nincs miről beszélni.
Ha téves lenne a bitszélesség infóm, és 64biten van szervezve a 4 chip,
akkor is csak 1144MB/s.
Ha tévedtem a bitszélesség tekintetében, akkor
1920x1440x32bit@60Hz (RAMDAC oldalról, minimális képfrissítésnél) =633MB/s
1920x1440x32bit@75Hz (RAMDAC oldalról, a max. gyári spec. szerint) =791MB/s
1920x1440x32bit@24Hz (CPU oldalról) =253MB/s
összesen: 886-1044MB/s, azaz 77,5-91,25%-os terhelés.
Az alig 9-24% tartalékot már néhány egyidejű frame írás/olvasás kérés felemészti.
Ha a RAMDAC olvasási prioritása nagyobb, mint a CPU oldal írásé (szinte biztos),
akkor képes fogni a processzort a keresztmetszet.
Tegyük át privátba ezt a vitát, amíg még trey ki nem vág minket innen,
és ha végleges és értelmes eredményre tudunk jutni, azt közöljük ugyanitt.
-
"Attempting to crack SpeedLock can damage your sanity"
Annyit még, hogy ezek szerint 32MB-os a kártya, ugye? (8MB-os chipekből 4db)
Mondjuk szerintem a legegyszerűbb kipróbálni erősebb gépben (húzással akár) jól megy-e, hisz ha jól értem a logikádat, akkor a vga-ra kell várnia a procinak, s legyen akármilyen erős a cpu, akkor sem lesz jó a lejátszás.
Szerintem egyszerűen csak gyenge hozzá a proci, ez pedig nem újdonság.
Szerintem ez a 64MB GF2 MX200 kártya, de két hasonló SFF gépem is van, majd megnézem a másikat is.
A proci terhelést vissza-tesztelem -vo null mellett, aktuális vga-tól függetlenül, csak procira vetítve.
-
"Attempting to crack SpeedLock can damage your sanity"
téves következtetés...
arról van csak szó, hogy hang dekódolás nélkül éppenhogy elég a teljesítmény a videó dekódolásához. De az is lehet, hogy így is dobálja a frameket, csak kevesebbet és nem tűnik fel. Ha egy erősebb gépen ugyanakkor indítod a lejátszást, mint ezen, akkor jó eséllyel kis idő múltán a kép és a hang is elcsúszik a referencia géphez képest.
amikor a hangot is dekódolja a rendszer, az cpu időt vesz el a videó dekódolásától és így jobban szaggat.
Azért ugrik/marad ki hang, mert kissé lassítva játssza a videót és néha összeszinkronizálásképpen átugrik hangrészeket, hogy újra együtt menjenek.
Ha frame dobás nélkül, kép- és hanghiba nélkül tudod lejátszani, az jó eredmény.
A framedrop nincs engedélyezve a lejátszónak, pont ezért.
A hang szinkron ugrással ezért valószínűleg igazad van,
mivel az MPlayernek nem marad más választása.
De akkor a -vo null esete mivel magyarázható szerinted?
(olyankor ugyanúgy dekódol, csak nem küldi a képet a vga-ba)
Egyébként már sokszor leírtam, hogy 2,5GHz-et számoltam határértéknek,
az adott konfig 2,4-es, mind az Intel, mind az AMD gép...
Húzzak az órajelen egy százast, és meglátjuk? :)
-
"Attempting to crack SpeedLock can damage your sanity"
nem hiszem el
A bitráta ismerete nélkül ez nem sokat mond.
Próbáld ezzel a videóval (torrent link):
http://tracker.hatters.org.uk/torrents/
Vagy a szokásos: http://images.apple.com/movies/us/hd_gallery/gl1800/1080p/bbc-blue_m108…
--
Discover It - Have a lot of fun!
Ezt az én gépem (C2D P8300 @2.4 GHz) az Ubuntu 9.10 szabványos mplayerével elég jól viszi, párszor szaggatott bele.
Amit linkeltem (x64_killa_sample.mkv a fájlnév), az gyakorlatilag diavetítés, még skiploopfilter=all:fast opcióval is.
szerk: elnéztem, egy másik volt az, ami beszaggatott. Ezt a BBC-st stabil 70% procihasználattal lejátszotta szaggatás nélkül. Maga a videó egyébként nagyon szép, már csak a búvárszemüveges Jessica Alba hiányzik belőle. :)
Nekem is viszi szó nélkül persze, de itt most az a kérdés, hogy a tesztalany hogy bírkózik meg vele.
--
Discover It - Have a lot of fun!
Közben lejött minden letöltés, a "KILLA SAMPLA X264" már elég kemény,
amikor már nem látni a madaraktól a földet, bizony szaggatni kezd szegény Athlon 2400+,
de egymagos Athlon 3000+-on, vagy Intel P4 3GHz gépen még simán járható lehet.
Szerk.:
"KILLA SAMPLA X264" lejátszást mértem újra, tényleg gyilkos a film, (naná, 33,8 MBps)
1998MHz-en ketyegő egymagos Athlon XP 2400+ (FSB266, Thoroughbred B mag)
a teljesen framedrop nélküli teljesítmény kb. 71%-ának előállítására képes.
(a méréshez letiltott framedrop-ot, azon kívül szemet, fület, és stoppert használtam...)
A szimpla Barton-magos 2600+-tól 3200+-ig még bőven esélyes lehet,
a nagyobb fsb, kétszer annyi cache, és eleve nagyobb teljesítmény miatt.
-
"Attempting to crack SpeedLock can damage your sanity"
Azért erről az x264 és 33.8 MBps-ről eszembe jutott valami...
ennyi erővel MJPEG is lehetne a kodek, lehet hogy még úgy is kevesebb helyet foglalna,
akár sokkal jobb képminőség mellett, és 1/4 processzorigénnyel...
Gyors, hozzávetőleges számítás szerint a helyfoglalás azonos minőségnél
lecsökkenhetne 2/3-ra, a gépigény pedig kb. 1,2-1,5 GHz-re, tehát Atom simán vinné.
-
"Attempting to crack SpeedLock can damage your sanity"
Tényleg szép a bbc film, de így böngészőből szaggat az egymagos Athlon 2400+ gépen,
arról nem beszélve, hogy csak 5MBit downlink van a gépnek...
Szóval letöltöm, aztán kiderül.:)
Letöltöttem,
és már kb. ötször megnéztem, olyan gyönyörű a BBC film. :)
(egymagos Athlon 2400+, 1998MHz, néha kattog kicsit a hang,
valószínűleg +100MHz már bőven elég lenne.)
Ugyanazon a gépen kipróbáltam wine alatt futtatott windows port MPlayer-rel is,
ugyanúgy ffmpeg kodekek, és így is megy, néha egy kis hang click szintén van.:)
-
"Attempting to crack SpeedLock can damage your sanity"
Még ez is elég hihetetlennek tűnik, pedig ennél egy mkv fogósabb.
--
Discover It - Have a lot of fun!
Ülj be a kocsiba, mondom a címet...ha nem hiszed el...
vagy szervezek egy nyilvános bemutatót.
Addig is letöltöm a fenti torrent linket is.
-
"Attempting to crack SpeedLock can damage your sanity"
Az még nálam is beszaggatott.
Azt mondd már el, milyen kapcsolókkal, vagy hogy indítod a lejátszást....
--
Discover It - Have a lot of fun!
A lejátszást indító script mplayer sora ez:
mplayer -fs -really-quiet -vo xv -ao oss -vfm ffmpeg -lavdopts fast=1:skiploopfilter=all $file
(ha nálad nincs oss, akkor írd át alsa-ra vagy openal-re,stb.)
-
"Attempting to crack SpeedLock can damage your sanity"
>nálad nincs oss
nalad van?
e: en ugy tudom h oss-t az utobbi idobe az alsa emulalja
Nem valódi itt sem, csak alsa emuláció, de nem feltétlenül és mindenkinél üzemel.
(bár javasolták már, hogy próbáljak ki egy valódi oss-t is)
Egyébként eddig az oss vagy az openal bizonyult a két legjobb választásnak.
-
"Attempting to crack SpeedLock can damage your sanity"
Aha, hát így 40-50%-kal viszi... Viszont kicsit darabosabb, mintha kihagyna jópár kockát, meg talán a kép se olyan szép.
--
Discover It - Have a lot of fun!
Kihagyni nem tud, mivel a kockadobás nincs engedélyezve, ezért az összes frame-et renderelnie kell.
A képminőség kicsit talán gyengébb, de az ember nem 30cm-ről néz filmet...
Ha normális, arányos "tv-néző" távolságból nézed, nem zavaró, észrevenni sem lehet.
Ha darabosabb, akkor bizonyos részeknél néhány pillanatra nagyobb a terhelés, és nem bírja a gép.
-
"Attempting to crack SpeedLock can damage your sanity"
Enélkül a kapcsolók nélkül gyönyörű minőségbe hibátlanul, folyamatosan viszi a gép.
--
Discover It - Have a lot of fun!
Mivel a géped egy C2D, 2x3GHz, ha jól olvastam feljebb...
Az egymagos lejátszásról szól az egész thread.
Az egész onnan indult, hogy könnyű rendszeren, jól sikerült lejátszóval,
esetleg skiploopfilter opcióval egy magon is mennie kell az 1080p-nek.
-
"Attempting to crack SpeedLock can damage your sanity"
A jelzett módon elindítottam, egy helyen volt egy nüánsznyi akadásom, alig volt érzékelhető.
A gép:
Athlon 3000+
2G RAM
NVIDIA 8400GS
OS: Ubuntu 9.10
Az MPlayerem a tárolóból van, nincs módosítva.
Nem szoktam HD videókat nézni (még simát is alig, annyit germózok napközben videóvágással), így fogalmam sincs, hogy ez ezen a konfigon jónak számít-e, vagy sem.
szerk.: prociterhelés lemaradt, stabilan a 90-100%-ot üti :D
Akkor a számítások jók voltak.
Kösz a próbát!
Könnyített, módosított cuccon erre elég a 2500-2600+ is.
(A 3000+ már a Barton magos, újabb verzió.
A 2500-2600+ még a régebbi Thoroughbred maggal értendő,
Barton-ból lehet, hogy elég a belépő szintű 266FSB-s 2500+ is)
-
"Attempting to crack SpeedLock can damage your sanity"
nekem volt 2500+-os Barton magos AMD-m, és úgy rémlik, hogy az 333 MHz-es volt, és dupla L2 cache-e volt a TBRED-hez képest...
--
by Mikul@s
Jól emlékszel, 512KB L2 van a Barton magos 2500+-ban.
Órajel és fsb szerint viszont kétfélét is gyártottak belőle.
http://en.wikipedia.org/wiki/List_of_AMD_Athlon_XP_microprocessors
-
"Attempting to crack SpeedLock can damage your sanity"
nos ezt tényleg nem tudtam, gondolom ezért: "Was released with very limited quantities, most probably an OEM-only CPU."
--
by Mikul@s
Tudod, hogy szól a mindenkori apróbetű...a gyártónak jogában áll akár mindennemű közlés nélkül is
változtatásokat eszközölni a gyártmányon, a vásárló tájékoztatása nélkül is...stb,stb...:)
Csak ne futnék bele állandóan ilyenekbe, még akár el is hinném, hogy tényleg csak szórványos jelenségek...:)
-
"Attempting to crack SpeedLock can damage your sanity"
A bitráta ismerete nélkül ez nem sokat mond.
A tesztfilm 10MBit körüli bitrátával van kódolva.
(kb. 9800+hang)
-
"Attempting to crack SpeedLock can damage your sanity"
hah, fullhd-ből ez eléggé low-end, nem ez a jellemző...
inkább a 15-22 mbps közötti+hang, ami néha felugrig egy-egy jelenet erejéig magasabbra.
ez variable... ha kevés a mozgás akkor sokkal kissebb a cpu mint ha több...........
A fenti videóból (killa sampla) grafikus kártyás gyorsítás nélkül nem sokat látok, a proci egy c2d e4600, (2x2.4ghz) egy mag 100%-on megy, és kb minden 10. képkockát látni. Szóval ha a fenti konfig viszi, az tényleg szinte csoda lenne. Szerintem sokakat érdekelne egy how-to a régebbi gépeken, esetleg netbookon való mkv lejátszásról. Nekem úgy tűnik hogy ezek a nagyfelbontású filmek akkor nyúzzák igazán a procit mikor sok, hirtelen mozgás van a képen. Kár hogy nem nagyon van agp-s nvidiaból ami tudna gyorsítani, biztos lenne pedig kereslet rá.
"mindössze a skiploopfilter opcióval" a siker záloga.
--
"I tried to get into business school, but on the qualifying exams, I passed the ethics test."
Azóta eltelt egy nap, készült egy MPlayer r30099-alapú build,
már "fast" és "skiploopfilter=all" sem kell,
az eredmény kezdi közelíteni az opciózott megoldást.
(a forrás változatlan r30099, a fordításnál viszont
csak az mkv lejátszás függőségei maradtak benne,
azon kívül minden egyéb holmi --disable- ,
de még a ritkábban használt -vo -ao kimenetek is.)
-
"Attempting to crack SpeedLock can damage your sanity"
Visszamértem ugyanazt a linux rendszert és lejátszó szoftvert,
ugyanazon próbafilmmel, egy AMD Athlon X2 4200+ gépen (2x2200MHz),
a gépben 768MB DDR2 van, és integrált nVidia GF6150, a CPU-terhelés 40-42% volt.
A tesztfilm még mindig ez:
http://hup.hu/node/84450#comment-979655
-
"Attempting to crack SpeedLock can damage your sanity"
Ez egy 350MB-os minta, két részre darabolva plusz egy ellenőrzőfájl a rarokhoz.
http://www35.zippyshare.com/v/95841050/file.html
http://www47.zippyshare.com/v/90980821/file.html
http://www29.zippyshare.com/v/50919219/file.html
A film adatai, amiből a minta ki lett szedve:
Bitráta: 15360 kbps
Felbontás: 1920x800
Fémráta: 23.976 frames/s
Mivel ez egy mozgalmas jelenet, a bitráta 25000kbit felett is lehet.
i7-860-as procin a rázósabb részeknél 60-70%-os terhelést okoz.
-
Ez az, amit nem sikerült a tárhelyre felhúzni, mert nem engedett be a szerver?
Már töltöm is!!!
Kösz!
Szerk.:
Letöltöttem, (Star Trek 2009 részlet) ettől már tényleg akadozik a hang, néha a kép is
a 2400+-os Athlonon, de játssza, nem sok hiányzik hozzá.
1 magon, 3GHz-ig bezárólag (vagy eq., 3000+) ennek is mennie kell.
-
"Attempting to crack SpeedLock can damage your sanity"
itt is van egy kupac tesztvideó:
http://prohardver.hu/teszt/asus_oplay_halozati_medialejatszo/proba.html
Thx:)
Este meg fogom nézni!
-
"Attempting to crack SpeedLock can damage your sanity"
Javaslom ezt: http://www.google.hu/search?hl=hu&q=sony+a+place+in+the+sun&meta=&aq=f&…
a videot a teszteléshez.
Ha már ez is megy a feni configon büszke lehetsz az os-edre ;)
----
概略情報
Töltöm, iszonyat lassan jön, még 20 óra a torrent vége...
(kíváncsi vagyok rá, de így -látatlanban- nem értem...MPEG2 HD, ~800MB...
a MainActor-ral szoktam renderelni MPEG2 HD kimenetet, azokat csont nélkül játssza ez a gép)
-
"Attempting to crack SpeedLock can damage your sanity"
Mpeg2-vel kár vacakolnod. Az x264-et sokkal nehezebb dekódolni. A killa.sampla.x264.mkv-nál nem fogsz durvábbal talákozni.
Szerintem sem, az megizzasztotta a tesztgépet, a szükséges átlag-teljesítmény 71%-át tudta csak előállítani...
(mondjuk attól a konfigtól lehet hogy még ennyi is világrekord...:)
-
"Attempting to crack SpeedLock can damage your sanity"
Ducks.Take.Off.2160p.QHD.CRF25.x264-CtrlHD.mkv mar lattad? :P
Az szerintem ugyanaz lesz, mint a "killa_sampla...", nem?
Kb. egymillió madár száll fel benne, és repül a földgömb fölött.
Ilyenektől sokszor még kétmagos gépek is mekegni kezdenek, akkora a bitráta érték.
(akkora a bitráta érték, hogy feléből MJPEG-be lehetne tenni, azonos -vagy jobb- minőség,
és 1/4-1/8 lejátszási CPU igény mellett)
-
"Attempting to crack SpeedLock can damage your sanity"
Nem, ez kacsak a to felett :) [megvan a killa is, nem uaz]
http://chibi-szasz.hu/killa.txt
http://chibi-szasz.hu/ducks.txt
Szerk.: megvan a forras is:)
ftp://vqeg.its.bldrdoc.gov/HDTV/SVT_MultiFormat/
A torrent már egy napja álldogál 99.6%-on...előbb-utóbb csak lejön...:)
-
"Attempting to crack SpeedLock can damage your sanity"
+1 :-(
Már 99,61%...soha nem fog lejönni...
-
"Attempting to crack SpeedLock can damage your sanity"
Azt megnéztétek mennyire szükséges a fő .ts lejátszásához az négy, öt töltelék file?
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
RAR, darabokban...hiányosan minimum CRC error.
-
"Attempting to crack SpeedLock can damage your sanity"
Az első .ts file tökéletesen nézhető, de a maradék .par fileoknak semmi közük nincs a RAR-hoz.
Így vagy nem ugyanarról beszélünk, vagy egyszerűen nem nézted meg.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
Torrent link, KTorrenttel húznám már több mint egy hete,
99.6-on áll, kicsomagolni pedig nem tudom, mert pont úgy hiányos.
-
"Attempting to crack SpeedLock can damage your sanity"
Én a torrentet töltöttem le, minek tartalma:
Nem töltődik végig ez sem, de ettől függetlenül nézhető az első file tökéletesen, mplayerrel is.
par emlékeim szerint sima txt.
--
http://opensolaris.org/os/project/indiana/
http://www.opera.com/browser/
+1
melyik a legolcsóbb kártya, amelyikben van vdpau? (és linuxon lehet is használni)
google a baratod... http://en.wikipedia.org/wiki/Nvidia_PureVideo#Table_of_PureVideo_.28HD…
ez hasznos
Dropbox:
https://www.getdropbox.com/referrals/NTI3NzY1ODQ5
Létezik HD videó-gyorsító pcmcia kártya is notebookokba. Arról tud linket valaki?
ExpressCard talán.
http://www.stealthimaging.com/products_dualExpress.html
Ennél kézenfekvőbb, költséghatékonyabb, energiatakarékosabb hardveres videógyorsítást támogató videókártyával venni laptopot.
Valaki avasson be, de egy arch+flux "disztro", frissen forgatott mplayer-mt-vel nem lenne ezekszerint nagy szó? (Mert ennél sztem gyorsabb lenne...)
Attól függ. Egymagos gépen (a téma arról szól) az mt nem fog hozni semmit.
A könnyű disztró viszont igen.
(cinikus magánvéleményem szerint, ha egy új szoftverről azt mondják, hogy még nagyobb teljesítményű lett,
mint az elődje, az általában csak azt jelenti, hogy nagyobb vas kell alá, és még azt is meg fogja enni...) :)
-
"Attempting to crack SpeedLock can damage your sanity"
Az igaz, higy egymagoson semmi értelme, de ugyanúgy régi hardverrel úgy is csak az xv marad.
Meg mindenki tudja, hogy az arch gyorsabb :)
Meg én abban a tudatban voltam, hogy a Suse egy átlagos Desktop distro, míg pl az arch könnyű disztro. Ha már a sebesség volt a lényeg mér nem valami gyorsabbat választottál?
[Teljesen tanulási szándékkal érdeklődöm :)]
Suse-hoz értek, 6.4 óta használom, nyugodtan neki mertem esni.
A SuSE nem egy átlagos disztró, stabilak és jók az alapjai,
eszméletlen bőséges és széleskörű a csomagválaszték,
de az utóbbi években nagyon "elhízott", és az enterprise státusz
-előnyei mellett- hátrányokat is hozott bele.
Nincs az az atléta, aki rekordot futna egy kamionnal
a csővázas hátizsákjában! :)
A tesztelő csapattal nekiálltunk a lényeges minimumot kihámozni belőle,
és az alkalmazás-csomag alá behúzott minimális függőségekkel
karcsú, és nagyon gyors lett az eredmény,
akár P2-366 gépen is használható.
-
"Attempting to crack SpeedLock can damage your sanity"
OKé :) Köszönöm :D
Ilyenkor jövök rá, hogy mekkora állat program is az mplayer :)
A fent említett Sample_Children_of_men -t se a VLC (1.0.2) se a Totem (2.28.2) nem tudta jóformán diavetítésen kívül sehogy lejátszani. Erre mplayer és megy akadozás nélkül. Az más kérdés hogy anyázik a konzolban, de kit érdekel ha megy a film? :)
Mellesleg egy E2200 Dual Core Pentium (2.2Ghz) és nVidia 8500GT -vel csak pislogok hogy miért is van egyáltalán problémám..
:)
A'rpi
Smplayer + nVidia VDPAU ( 8000-res szériától fölfele van ) :)
CPU meg sem nyikkan.
|| "Software is like sex: it's better when it's free." Linus Torvalds || Visit Gorkhaan's Homepage
http://hup.hu/node/85064#comment-998131
Igazad lett, a .ts már itt is szinte hiánytalanul lejött, a többi pedig lényegtelen.
Gyönyörű szép, eszméletlen részletes, és persze csodálatos zenei aláfestéssel...
kb. feléig-kétharmadáig , ahol hiányzó motion vector-ok miatt panaszkodni kezd az mplayer,
ott már néhány ponton hiányos lehet a letöltésem.
Addig a pontig akadás nélkül, (és opciók nélkül), 85% körüli total load mellett
az AMD Athlon XP 2400+ (egymagos, 1998MHz) gépen, GF6200 AGP VGA-val, teljesen szoftverből.
-
"Attempting to crack SpeedLock can damage your sanity"