HD MKV teszt

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á.

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"

"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.

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.

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"

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.

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"

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. :)

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"

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"

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"

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"

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 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á.

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"

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"

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"

Én a torrentet töltöttem le, minek tartalma:

Cmp Pri              Size           Filename
            0                          828,0 M | SONY HD - A Place in the Sun 1080i.ts
            0                          0,0 M      | SONY HD - A Place in the Sun 1080i.ts.par2
            0                          0,4 M      | SONY HD - A Place in the Sun 1080i.ts.vol00+01.PAR2
            0                          0,8 M      | SONY HD - A Place in the Sun 1080i.ts.vol01+02.PAR2
            0                          1,6 M      | SONY HD - A Place in the Sun 1080i.ts.vol03+04.PAR2
            0                          2,0 M      | SONY HD - A Place in the Sun 1080i.ts.vol07+05.PAR2
            0                          3,8 M      | SONY HD - A Place in the Sun 1080i.ts.vol12+10.PAR2

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/

melyik a legolcsóbb kártya, amelyikben van vdpau? (és linuxon lehet is használni)

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"

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..

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"