Susie Labs: HD videók lejátszása egymagos processzoron

Little Susie

Egy hete írtunk arról a fórumon, hogy egy javított régebbi MPlayer segítségével 1080p wmvHD videót tudtunk lejátszani, a Microsoft által ajánlott minimális hardverigényhez képest 2/3 CPU, és 1/3 RAM felhasználásával.

Aztán a vita után -bár csend sokáig nem lett- a Nyájas OLvasó már majdnem fellélegezhetett, gondolván, hogy ezt a hétvégét már sikerült megúszni Little Susie cikk nélkül! Hát nem, mert itt jön a mára esedékes "CoV rulez"...:)

A fórumon rögtön többen ajánlották, hogy teszteljünk az alacsony konfigon MKV videót is... nem mintha valós igény volna rá... á, dehogy...hiszen többek szerint hazánkban kabátzsebben, napilapba csomagolva, csak úgy párizsis zsömle gyanánt már mindenki QuadCore processzorral szaladgál, a másik zsebben meg nVidia GTX260-nal, utóbbi is csak azért kell, mert ha levesszük a rézcsöves Zallmann hűtőt, akkor pótolja az otthon felejtett öngyújtót is, hogy hamarjában gyújthassunk akár hetyke palóc pipára -dohány gyanánt megfelel bele szinte bármelyik mai, hazai nyomtatott IT sajtótermék jól kiszárított, csíkozott papírja is- a két villamos egység pedig együttesen fűtheti a kabátot, ilyenkor télvíz múlta idején...:) Ha mégsem, akkor -mint én is tettem- érdemes az alábbiakat kipróbálni.

(Kisebb, -kivetítő nélkül, így szemre még nem bántó- minőségi áldozatok árán, de hamarosan sikerült az 1080p MKV/H264 is, tehát 2-3GHz közötti erősebb kivitelű egymagos gépen, akár már 256MB RAM-mal meg lehet próbálkozni 1920x1080 vagy 1440x1080 felbontású MKV/H264 film lejátszásával, Susie béta alatt.)

Az MPlayer és a w32codec csomag letölthető innen:
http://borzsonynet.hu/linux/LSfKDE3/MPlayer-1.0rc2_r27637-2.pm.1LSfKDE3…
http://borzsonynet.hu/linux/LSfKDE3/w32codecs-20071007-1medibuntu5.i386…

(telepítés előtt nem árthat a csomagkezelőben -függőségeket felülbírálva- a meglévő MPlayer eltávolítása)

MPlayer a szokásos helyre és menübe települ, az MKV lejátszó pedig a (K)menü > Alkalmazások alá.

Mivel a Susie Projektet az a -teljesen jogos- vád érte, hogy a közlések bőbeszédűek, és nem eléggé szárazon szakmaiak, álljon itt az ominózus MPlayer patch, és -mivel az az új úri huncutság, a C-nyelv is nagyon bőbeszédű- csak tömören, hexában. :)

mplayer, (openSUSE 10.1, Packman, 1.0rc2_r27637-2.pm.1 csomagból)
0002:4318 38
0002:4319 35
0002:6686 35
0002:20e5 31
0002:20e7 32
0002:20eb 30
0002:20ec 00

( asci v | 2010. 03. 22., h – 09:40 )

Valószínűleg egyesek falra másznak ettől a szövegtől, de nekem tetszik :)

Azok mikor meglátják a címben "Susie Labs" kifejezést akkor sarkonfordulnak :) én legalábbis tudatam mire számítsak ;) de hogí valami építőt is írjak, nekem szem .szer. bejön a törekvés, és mivel Opensuse user vagyok lehet legközelebb fel is teszem, mert azokat gyarapítom, akiknek nincs QuadCore-os gépe.

java'nother blog

Háromféle olvasó számára készülnek ezek a cikkek:
-akiknek szükségük van rá, és használható dolgokhoz jutnak általa, teljesen ingyen
-akiknek tetszik a szöveg, függetlenül a gépük aktuális teljesítményétől és a rajta lévő OS-től
-valamint a fenti két halmaz metszetének :)

(csak azt nem értem, hogy akinek nem tetszik, és nem is érdekli,
az miért olvassa el...van valakinek használható ötlete?)
-
"Attempting to crack SpeedLock can damage your sanity"

Hát ezt szépen megasszondtad. :)Erről jut eszembe még évekkel ezelőtt, középsuliban kédeztem ismerősömet, hogy milyen szivattyúk vannak, mert dicsekedett vele, hogy ők is tanulták ám. A válasz azonnal jött: "örvény", majd 5 mp gondolkodás és "egyéb!". :)
Azóta nem kérdezek tőle ilyet. :)

-- "Bízzál Istenben és tartsd szárazon a puskaport!" - Cromwell --
-- Sayusi Ando - http://sayusi.hu --

Az ilyen emberek képtelenek elfogadni hogy akadhat olyan dolog a világon ami nem tetszik nekik. Viszont agyilag még nem jutottak el odáig hogy ilyenkor ne nézzenek oda és kerüljék el nagy ívben azt a valamit. Nem, ők odamennek, beleugatnak, aztán a tettek mezejére lépnek és fejszével, pörölykalapáccsal vagy más hasonlóan kifinomult eszközzel megpróbálják a saját szájuk íze szerint átalakítani. Ha ez nem sikerül akkor fölrúgják és dühödten ugrálnak rajta amíg ki nem lóg a nyelvük.

( the_nameless89 | 2010. 03. 22., h – 10:22 )

Rendkívül nagyra értékelem a munkátokat, de szerintem ezzel a hozzáállással elég hamar meg fogjátok utáltatni magatokat a közösséggel. Nekem nincs bajom veletek, de nagyon sok felhasználónak van. Ezek a fejlesztési "mérföldövek" egyáltalán nem ide valók, sőt nem is hírértékűek. Dobjatok fel a tárhelyetekre legalább egy Wordpress blogmotort, aztán abban vezessétek a dolgokat. Ti pont az UHU Linux ellentétei vagytok. Róluk szinte tudni sem lehet, rólatok meg mindent, ha kell, ha nem. Azzal viszont nem lesztek sikeresek, ha minden légyfingról hatalmas bejelentést tesztek. Persze jelenjenek meg hírek a fejlesztésekről, de a ti oldalatokon. Ide, vagy bármelyik informatikai portálra csak a kiadások bejelentései kellenek, a többi csak spam, amit előbb utóbb mindenki meg fog utálni.

Egyáltalán nem negatív kritikaként mondom. Az olyat én is utálom és én sem szívesen kritizálom más munkáját. Ezt inkább csak vegyétek tanácsnak egy olyan embertől, aki már látott és tapasztalt egyet, s mást az évek folyamán.

SKL - leírásgyűjtemény és informatikai portál

Nem vitatkozom, sok mindenben igazad lehet,
de ezen az alapon a HUP cikkek kétharmada meg sem jelenhetne...
(Amikor az MS, a Google, az Apple, az Ubuntu, vagy bárki más dob egy aktuális marketing bullshit-et,
az miért fér bele szó nélkül? Ha eleve nem érdekel már a címe sem, akkor nem olvasom el...)
-
"Attempting to crack SpeedLock can damage your sanity"

Ebben azért van valami kollégák.... Mikor MS-ék bejelentenek valamit, az mitől unixos hír (mert hát ugye Hungarian Unix Portal). A Suie még mindig több unixos gyökérrel rendelkezik, mint egy MS rendszer (ok, tudom, most nagyon csőlátású voltam, beismerem. Viszont inkább szívesebben olvasom egy ilyen kis, de lelkes csapat napi örömeit, mint hogy ki milyen szabadalomi baromságai miatt pattogtatunk kukoricát. Megjegyzem, hetente mostanság minimum2-3 alkalommal. Ezzel az erővel a heti egy Susie bőven belefér, még ha néha infantilisnek is tűnik egy-egy hír).

Az a nagy alácsüngő helyzet hogy a hülyeségből nekem csak villanásaim vannak olyanok mint egy valamikori kollégámnak az átlagos nívója volt. Nem tudom hogy azóta - kb. 20 éve - kiheverte-e ezt az áldást. Hiába no, erre születni kell. Én a gyári végellenőrzés alkalmával éppen csak megütöttem a megfelelő szintet. (Bele is kékült.)

Nyilván van akit ez zavar, de át lehet ugrani, nincs az a hírdömping, ami miatt ne férne el itt a HUPon. Személy szerint engem szórakoztat, és ezzel a korábbi hozzászólások alapján nem vagyok egyedül, az információ-értéke meg legalább annyi van mint pl. bármelyik expo-ról szóló rövid "az xy cég bemutatta a z termékét" típusú hírnek. Flame meg lesz azok alatt is meg itt is, ez már csak ilyen, nem kell vele foglalkozni.

"Rendkívül nagyra értékelem a munkátokat, de szerintem ezzel a hozzáállással elég hamar meg fogjátok utáltatni
magatokat a közösséggel. Nekem nincs bajom veletek, de nagyon sok felhasználónak van."

LOL. Erről az a vicc jut eszembe, amikor Pistike bemegy a gyógyszertárba óvszert venni a barátjának. Miér kell leszólni azt, aki lelkesen csinál valamit a közért? Miért zavar egyeseket az ha, valaki örül valaminek? Muszály leszólni? Tipikus magyar szokás sajnos, dögöljön meg a szomszéd tehene. Én speciel közelében sem vagyok a SUSE-nak, de örömmel olvasom, ha bárhol, valakinek sikerélménye van.

Csak így tovább, és sok sikert további fejlesztéshez!

( necrolite | 2010. 03. 22., h – 10:28 )

Kikerem magamnak... GTX 285 Black Edition van ;o)

( Zaneck | 2010. 03. 22., h – 10:33 )

Egy low profile videókártya kevesebb mint 50 dollárért hardveres videógyorsítást támogat. Egy korszerű 300 dollárért összeállítható konfiguráció áramfogyasztása nagyon alacsony.

Ahhoz, hogy az 1080p-nek értelme legyen egy nagyobb kijelzőre van szükség (legkevesebb 150 dollár).

Miről is beszélünk?

Mellesleg az előző témában hivatkozott 1080p-s wmvHD Robotica videót Intel Pentium III 1.4 Ghz (Nvidia Geforce 3) és Intel Pentium M 1.2 Ghz (Intel 855GM) rendszereken lejátszottam MPlayer-rel, hardveres gyorsítás (csak XVideo) és skiploopfilter nélkül, 80-90%-os CPU terhelés mellett folyamatos volt a kép.

Próbálkozz más 720p és 1080p forrásokkal, az egymagos processzor nem elég hozzájuk hardveres gyorsítás hiányában.

Nem mindenki (en se) akar gepet bovetni, meg akkor sem, ha ingyen adnak, mert lusta vagyok most nekiallni ennek :) Tudom, ez az en problemam. Szuksegem sincs ilyen folbonastu videokra, az is igaz. Viszont, ha valatlenul pont ilyen kerul a kezembe, akkor jo otlet lejatszani ertelmesen, anelkul, hogy csak emiatt gepet bovitsek, vagy transcode-olni kelljen, foleg, ha nem egy gyakori eset a dolog ...

Tudod, akadt a negyvenes évek elején egy angol mérnök, aki részt vett a radar fejlesztésében.
Egyszer már nagyon éhes volt túlóra közben, és egy tábla csokoládét kezdett el enni...
aztán kiszaladt egy percre, és a csokit a próbapadon hagyta, a bekapcsolt berendezés alatt.
Ha akkor éppen nem eszik csokoládét, nem látogatja meg a vizeldét, és a csokit nem hagyja addig
a -szabálytalanul- bekapcsolva hagyott radar-fejegység alatt...
akkor most nem lenne mikrohullámú sütő.
Never say never!

-
"Attempting to crack SpeedLock can damage your sanity"

Emlékszel még az első ISA-s DVD-lejátszó kártyákra?
(MATSHITA drive, DOS-os, szoftveres ASPI-emulátorral az IDE buszon,
+ISA kártya, MPEG2+MP2 dekódoló hardverrel, a VGA feature csatira kötve...)
Vagy a MOOVE...esetleg az ISA-s Aztech Video Galaxy...
Mind-mind túlszárnyalhatatlannak tűnt akkor, aztán megjelent a vmpeg,
go32 alapon, DOS alatt, és vidáman dekódolta az MPEG1-et,
aztán a XING MP2 playere win31 alatt, és eljött a nagy dobás is,
Justin Frankel megírta...nem, még nem a Winamp...a DOSAMP-ot,
benne a Nitrane MPEG motor első verziójával,
ami gyengébb mp3-akat már néha bikább 386-on is...
Ma Wolfgang Hesseler számít az egyik abszolut legnek,
bár már két éve hallgat, és nem ad ki semmi újat...
-
"Attempting to crack SpeedLock can damage your sanity"

A GPU alapú dekódolás ennek ellenére is kifizetődőbb, különösen, hogy manapság a GPU-kat a CPU-ba integrálják (eddig az alaplapra integrálták őket), nem opcionális kiegészítők, mint az MPEG dekóder kártyák.

A 3D gyorsítás is kivitelezhető szoftveresen, de egyes számításokat sokkal szerencsésebb a GPU-val végeztetni.

Meg aztán ott a GPGPU, amikor olyan számításokat végeztetünk a GPU-val amiket hagyományosan a CPU-val tennénk.

Az elavult konfigurációkról még annyit, hogy mégis mennyi a hardvereszközök élettartama? Néhány év. A fenntartásuk, üzemeltetésük pedig akár többe is kerülhet.

Akkor miről beszélünk?

Többek közt arról is, hogy Linuxra -nVidia VDPAU kivételével- jelenleg nincs hardveres HD gyorsítás.
Ha egy magon elmegy, akkor egyrészt a kisebb gépeken is működik,
nagyobb gépen (mondjuk 2 magos) pedig csak egy magot dolgoztat.
Arról még nem is esett szó, hogy a hordozható (laptop/notebook/stb...)
gépek szignifikánsan nagy részében integrált Intel VGA van.
-
"Attempting to crack SpeedLock can damage your sanity"

A jelenlegi magyar gépállomány átlag 10-20%-ában benne van a lehetőség,
a többiben nincs. Itthon nem cserélődik olyan gyorsan a hardver,
és az sem árt, ha a szoftver -úgy általában- optimálisabb lesz.
(nem feltétlenül csak MPlayer-re gondolok)
-
"Attempting to crack SpeedLock can damage your sanity"

A Geforce 8500 GT a Linux-os Nvidia driverrel nem használható, annak ellenére, hogy VDPAU A kompatibilis (PureVideo VP2).

Windows-on használható:
- Teljeskörű hardveres gyorsítás (H.264)
- Részleges hardveres gyorsítás (MPEG-1, MPEG-2, VC-1/WMV9)

Linux alatt csak a Geforce 9-es széria (és azokra épülő kártyák, mint a 8400 GS) és az újabbak támogatottak.

Ahhoz, hogy az 1080p-nek értelme legyen egy nagyobb kijelzőre van szükség (legkevesebb 150 dollár).
IBM P260 21" CRT, vagy hasonló típus pl. már 8-10E Ft-ért is kapható, nagy képernyős, és 720p vagy 1080p-hez illeszkedő
felbontásokban is olyan képet produkál, hogy azzal borotválni lehet, jobb TFT-k is simán elbújhatnak mögötte.

1080p-s wmvHD...skiploopfilter nélkül
Valaki olvassa már el végre azt is, hogy a wmvHD esetén MI SEM HASZNÁLTUNK SEMMILYEN KÉPRONTÓ OPCIÓT.
Egy hete mondom már, de sokan csak a saját postjaikat olvassák, tisztelet a kivételeknek.
-
"Attempting to crack SpeedLock can damage your sanity"

"IBM P260 21" CRT"

Ennek az ajánlott felbontása 1600x1200.
TEhát 1080p fullhd-t értelmetlen nézni rajta, 720p -t meg a régi, 1.5ghz-s centrino m laptopom is akadásmentesen játszott 512MB RAM-mal winxp alatt.

"Valaki olvassa már el végre azt is, hogy a wmvHD esetén MI SEM HASZNÁLTUNK SEMMILYEN KÉPRONTÓ OPCIÓT."
Szerintem ez azért nem érdekli az embereket, mert ki néz wmvHD-t??
A nagyfelbontású filmeket letölteni (ami magáncélra legális magyarországon) 95%-ban .mkv -ban lehet.

No de a maximális felbontáson szerinted "natívan" meg fog neked jeleníteni mindent?
Van annyi képpont rajta?
Vagy azért 1600x1200 az ajánlott felbontása, mert a 0.24 dotsperinch pont ennyi egy ekkora monitoron?

Persze amúgy, egy 17" TFT-t, aminek a natív felbontása 1024x720 is be lehet váltani 1920x1200-ba, csak van-e értelme?

A függőleges felbontás teljesen rendben van.
1440x1080 esetén a vízszintes is.
1920x1080 esetén a vízszintes felbontás (a valós képpont-számra vetítve)
mindössze 3dB képminőség-romlást okoz, és azt is csak az egyik tengely mentén,
tehát teljes képre számolva az átlag 1-2dB között van.

Az az ember, aki ennyit szabad szemmel észrevesz, még nem született meg.
-
"Attempting to crack SpeedLock can damage your sanity"

A hasznos jel maga a VGA-ból kiömlő képpont-információ,
a zajos csatorna a 0.24mm dp IBM monitor,
ahol kb. 1690 valós vízszintes pixelen vetítünk adott esetben
1920-as felbontásban, mivel az adott monitor fizikailag tud ennyit,
csak a képcső nem eléggé "részletes" felbontású.
A zaj a fenti "csatorna" korlátaiból keletkezik,
részben a hasznos információ-tartalom csökkenése,
(aluláteresztő szűrő) részben pedig aliasing-jelenség formájában.
(Nyquist és Shannon bácsik óta eléggé jól kalkulálhatóan)
Ennek számított (részben pedig becsült) értéke
ez esetben a fenti konkrét -3dB, illetve a becsült átlag -1-2dB.
-
"Attempting to crack SpeedLock can damage your sanity"

Oké, akkor pontosítsuk: a számított értékek maximum-értékek,
(az adott csatorna maximálisan változó "információ-tartalma" esetén)
az általad említett kék kép pedig az egyik lehetséges minimum.
Tehát maximum 0 és -3dB között,
átlag pedig 0 és kb. -1,5dB között,
utóbbi jórészt az emberi szem tehetetlensége,
és átlagoló képessége miatt.

Az eredeti hipotézis az volt, hogy nincs az az emberi szem,
amelyik ilyen kis mértékű minőségromlást észrevesz,
pláne folyamatosan változó tartalom esetén.
-
"Attempting to crack SpeedLock can damage your sanity"

Igaz. Köszi, csak félreolvastam valamit. Így már érthető.
Az entrópia tényleg fontos, mivel létezik olyan speciális tartalom, ahol semmit nem lehet látni, de olyat is tudok neked csinálni, ahol bőven észreveszed. A természetes videó ugyanakkor tele van speciális tartalmakkal, szóval nem lehet kijelenteni, hogy ezt az ember nem látja. Fogalmazzunk úgy, hogy a gyakorlatlan szem nem látja. 3dB olykor nagyon kevés, de tud marha sok is lenni.
A 3-2 pulldown-ból származó judder-t is észreveszed, csak legfeljebb nem tudatosul az agyadban, hogy ez gáz, mert nem ismered a jelenséget, nem vagy vájt-szemű.

Nem a kijelző felbontása érdekes, hanem a fizikai mérete.

Egy 21"-os 4:3 képarányú CRT kevesebb felületet jelent 1080p esetén, mint egy 18.5"-os 16:9-es LCD.

Nem állítottam, hogy használtál skiploopfiltert, csak azt, hogy én nem.

Akárhogy is az HD videólejátszás nem valós igény 4 évnél régebbi konfigurációkon és szélesvásznú LCD kijelzővel nem rendelkezők körében.

( n0b0dy | 2010. 03. 22., h – 10:33 )

Többet ért volna, ha nem a cikk elején lett volna a bőbeszéd, hanem inkább a patch lett volna C-ben.

MPlayer a szokásos helyre és menübe települ, az MKV lejátszó pedig a (K)menü > Alkalmazások alá.

Akkor most mi ez az "MKV lejátszó"? MPlayer, speciális beállításokkal?

( mzperx | 2010. 03. 22., h – 10:45 )

Engem érdekel a dolog függetlenül attól, hogy GTX260-nál nagyobb kártyám van és jó hogy kikerült a főoldalra. De egy patch-elt forrásnak még jobban örülnék!

Nincs forrás, a patch közvetlenül hexában készült, az adott bináris fájlon, egy sima KHexEdit segítségével.
VDPAU-t viszont nem támogat ez a build, kimondottan low-end, vagy régi gépek részére készült,
viszont -ettől függetlenül- komolyabb cuccon is jól jöhet, érdemes kipróbálni.
-
"Attempting to crack SpeedLock can damage your sanity"

"a patch közvetlenül hexában készült, az adott bináris fájlon"
?! FAIL. Egy opensource programon ilyent elkovetni... Raadasul mi a garancia, hogy ez a patch tenyleg azt csinalja, amit mondasz? Ne haragudj, de ez egyreszt felelotlenseg, masreszt pedig... hat nem is tudom.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Ha megnéznétek a megadott patchet hexaban a megadott fájlon,
három perc alatt "portolhatnátok" bármelyik linuxra...

Teljesen nyílt a patch, gépi kód névre hallgató nyelven készült,
és nyított a patchelt bináris is, letölthető forrásként és lefordítva is.
Mi zárt ezen? A gépi kód? Sehol nincs előírva, hogy programozni csak C-ben lehet...
ha csak C-ben lehetne programozni, egyáltalán nem lenne MPlayer...
kérdezzétek meg A'rpi-t, hogyan fért volna el kb. 5k-ban
a legendákban emlegetett MPEG lejátszó ős-kód, ha C lett volna a nyelv...

Egyébként meg éppenhogy megosztottam mindenkivel, reprodukálható,
azontúl, hogy a termék (a Susie) is ingyenes linux, mint bármelyik másik...:)

-
"Attempting to crack SpeedLock can damage your sanity"

Én még túrtam speedlock-ot egy szál CP/M dumppal...írtam is direktben rengeteg tömör m/c kódot.
Jelen esetben kicsit nehéz lett volna pontosabban és rövidebben megfogalmazni azok számára,
akik esetleg még most sem értik ezt az egészet.
-
"Attempting to crack SpeedLock can damage your sanity"

A leírt tesztkörnyezetben megvalósul a leírt teljesítmény,
viszont se Arch-on, se Ubuntun nem próbáltam, azt "zengje más dalnok" !:)
A "műsorunk" viszont annyira jó lett, hogy a nézettség megüti
egy fajsúlyosabb Google, Mozilla, Ubuntu vagy MS hír olvasottsági értékeit.
Ismerve az átlagos magyar szokásokat és mentalitást,
már ez önmagában óriási eredmény lenne. :)

Tényleges, létező, hazai tábor kell, és ezerrel dolgozunk érte.
-
"Attempting to crack SpeedLock can damage your sanity"

Olyan nagy keres, hogy kinyogd, egyaltalan honnet vetted ezt a hekket, es mit csinal? Esetleg atportolni forrasra? Ne is haragudj mar, de te vagy a developer, neked kell segitened a mi munkankat, nem nekunk elvegezni a tiedet. Probalj mar egy kicsit normalisabban hozzaallni a dolgokhoz ember, mert a sajat renomedat rontod.

A masik az, hogy baromi nagy kulonbseg van akozott, hogy valaki assemblyben fejleszt es leforditja, meg akozott, hogy valaki egy mar letezo binarishoz ad valami hexa hekket, amirol senkinek fogalma sincs, hogy mit is csinal pontosan. Legyszi, ne nekunk kelljen mar a te disztribuciod fejlesztoi dokumentaciojat megirni, hanem legy oly kedves te megtenni ezt.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

http://hup.hu/cikkek/20100322/susie_labs_hd_videok_lejatszasa_egymagos_…

Teljesen felesleges dolog forrásra "portolni"...ágyúval verébre...
Dokumentáció írását sem kértem. Az a hét bájt magáért beszél.
A gondolkodásmód kapcsán pedig tényleg halkan szeretném megjegyezni,
hogy a developernek van munkája. A közösség pedig segítheti,
és akkor a developer közzéteszi amit csinált.
De nem fordítva.

-
"Attempting to crack SpeedLock can damage your sanity"

( Replaced | 2010. 03. 22., h – 11:43 )

ezt igy fyi egy ion/atom cejg is minden gond nelkul viszi win7 alatt

--
NetBSD - Simplicity is prerequisite for reliability

( twinsen | 2010. 03. 22., h – 14:11 )

Biztos én nem értettem a cikk lényegét (talán a stílus miatt), de mi érdeme van Susie-nak abban, hogy egy patchelt mplayer videót játszik le?
Lett belőle egy csomag és egy új menüpont? Ez a hír?

És mi ez a titokzatos patch? Igazán jó poén a hexa (bár ennek a tömörséggel ellentétben nulla az információtartalma), de ha esetleg lenne rá egy link is... olvasható formában. Tényleg csak kiváncsiság, mivel lehet megváltani a világot, amire az ffmpeg/mplayer team nem jött rá?

( hokuszpk | 2010. 03. 22., h – 15:52 )

hm. triplakóros gepem van, elgondolkodom unlockoljam-e a negyedik magot, es ha igen, minekis :D)

( xclusiv v | 2010. 03. 22., h – 16:36 )

(Tudom, ha nem érdekel akkor ne szóljak be hanem csak ne olvassam, de ezt most muszáj leírnom.)

Amikor elkezdett elszaporodni ez a szuzi dolog a hup hírek között, akkor hamar eldöntöttem, hogy engem ez baromira nem érdekel, skip-peltem a híreket.

Most ezt megnyitottam, mert a cikk címe érdekesnek tűnt, gondoltam hátha hasznos dolgot találok benne. Hát, nem találtam.

Szófosás - szuzi - szófosás - blabla -link - szófosás - szófosás - vége, kommentek.

8 éve regisztráltam a HUP-ra, legalább azóta rendszeresen olvasom, de ilyen szemetet eddig csak a fórumban olvastam, ott is elég ritkán.

Muszáj az ilyen "minőségű" "kontetot" cikkek közé engedni?

( Darkcomet | 2010. 03. 22., h – 21:42 )

Szerintem eleve vicces az egész. Ugye aki HD tartalmat akar nézni, ez eleve kalkulál vele a gépe megvásárlásakor ill. fejlesztésekor, tehát valamilyen szinten ráizmol a kérdésre. Akinek meg gyenge gépe van, azt meg nem is nagyon érdekli a dolog. Vagy mert másra használja, és arra a célra bőven kielégíti a konfigja, vagy esetleg tényleg nincsen ilyesmire pénze, na azt meg pláne nem egy HD mkv lejátszása fogja a menybe juttatni, pláne, hogy valszeg az ilyen felhasználónak hozzá való monitora, tévéje sincs, meg esetleg terrás, félterrás winyokkal sem nagyon van megáldva a gépe. Aztán vannak a hozzám hasonló elvetemültek, akiknek ugyan alkalmas lenne rá a gépe, csak éppen nem nagyon érdekli a HD tartalom, de ez egy egészen más kategória. Szóval tisztelet és becsület a munkátokba, de nem kéne valami értelmesebb feature-be áldozni az energiát és az időt? Arról már nem is beszélve, hogy egy-egy bejelentést tényleg nem kéne ilyen bő lére ereszteni, mert amíg a mezei user eljut a tényleges mondanivalóig (már ha rögtön az első bekezdés után meg nem unja), bőven elmegy a kedve az egésztől.

Többről van itt szó, mint holmi poénos cikkecskéről, bő lére eresztve.
A lényeg a szűkszavú, hét bájt adat a végén.
Az a néhány olvasó, akik elég kíváncsiak voltak, és megnézték már az adott binárist hexa editorral,
esetleg a régi eredetit is, és értették is amit láttak, (igen, aki eddig eljutott, az már nagyjából érti)
szóval ők most éppen kapkodnak a fejükhöz, és lehet, hogy már ezerrel túrják a linuxot-
hasonló "parajelenségekért".
-
"Attempting to crack SpeedLock can damage your sanity"

( mzperx | 2010. 03. 23., k – 00:04 )

Nem bírom ki, hogy ne mondjam el, hogy Én megnéztem mit csinál ez a pár bit és nagyon érdekesnek találtam és zseniális megoldásnak. Ez túl mutat az mplayer-en és bármilyen disztribúción. Igazi informatikai ((hacker )) gondolkodásmódot tükröz amit nem lehet tanulni. Remélem mindenki újraolvassa a hozzászólását a témához és elgondolkodik azon, hogy máskor mihez mit szól hozzá! Ami még megdöbbentő az az, hogy senki nem vette a fáradságot, hogy megnézze.

Akkor, -mzperx utólagos engedelmével- következzen -rövidítve- az a levélváltás, ami a háttérben történt!

"Akkor ez így gyakorlatilag bármit csinálhat nem? Én szeretem látni mi
történik a prg.-al. Amíg nincs rendes forrás amit meg lehet nézni,
addig veszélyes is lehet?!"

Nézz bele a binárisba, hexa editorral, a megadott offszeteken, és
garantálom, hogy a földön fogsz fetrengeni a röhögéstől...:)
De el ne mondd a többieknek, hogy mit láttál...hadd törjék a
fejüket, mert nem látják a fától az erdőt.:)
(Az RPM-ből az mplayer binárist egy Krusader-rel is ki tudod szedni,
aztán pl. KHexEdit-tel belenézhetsz a megadott pontokon)

üdv.,
H.I.

----------------------------------------------
Hello!

Ez tényleg nagyon jó! :)

libmpcdec.so.5
libx264.so.85
libdirectfb-1.2.so.0

Senki, még Én sem vettem a fáradságot, hogy megnézem pedig nagyon jó ötlet.
Most megnéztem a szálat és hát nagyon sok tanulsága van a dolognak.
...
És ez pusztán elég? Mi van a külön paraméterezéssel?
---------------------------------------------------

Nem ilyen egyszerű, de nem bonyolult.:)
az eredeti állapot libmpcdec.so.3 , libx264.so.64 , és libdirectfb-0.9.so.24 volt,
mert ez egy annyira régi mplayer bináris.
Eredeti állapotában nem alkalmas mai linuxon futtatásra, ezt újrafordítással lehetne
orvosolni, de az szinte lehetetlen a források többéves változásai miatt.
Lehetne szépen írni egy wrappert, ami kitűnő, és szép, és iskolás, de
egy köztes réteg -próbáltuk modellezni- esetleg megenné a teljesítmény-többletet.
Nem túl elegáns az, amit utolsó előttiként alkalmaztunk: egy RPM csomag
3 linkkel, ami átirányítja a régi mplayert az új libekre.
A legegyszerűbb-leggyorsabb -és hét bájt hexában nyílt forrású- megoldást
te láttad az olvasók közül elsőként...:)

A lényeg: a régi mplayer egy valamiért ritka jól sikerült build,
(eddig a saját forrás-csomagjából sem tudtuk reprodukálni...)
és ha összekerül a mai legmodernebb libekkel, és kodekekkel,
egy nagyon kikönnyített, gyors, kicsi linuxon,
akkor akár 2-2,5-szeres teljesítményt is lead.
(a mai openSUSE 11.1 buildekhez, de valószínűleg bármihez képest is)

Ez egy rejtett üzenet is, és nem azoknak, akik "tegnap is hozzáadtak
egymillió C sort a kernel forrásához", hanem azoknak,
akik még talán emlékeznek a kézzel kódolásra.
Hátha elindul belőle valami. :)
üdv.,
H.I.

-
"Attempting to crack SpeedLock can damage your sanity"

DirectFB nincs (lassabb az XVideo-nál).

Intel Pentium III 1.4 Ghz (kernel 2.6.32.10, nvidia 96.43.16, xorg-server 1.7.6, mplayer 30886, ffmpeg 22511)
közel megegyezik a CPU terhelés

Intel Pentium M 1.2 Ghz (kernel 2.6.27.45, xf86-video-intel 2.3.2, xorg-server 1.6.5, mplayer 30818, ffmpeg 22152)
forrásból fordítva, optimalizálva, 5-10%-al kisebb CPU terhelés

A tesztben AVC1-es 1280x720-as 23.976 fps-es videót használtam FFMpeg H.264-es dekóderrel.

A mellékelt MPlayer 27637 nálam semmivel sem gyorsabb, sőt. A disztribúció mindkét rendszeren Arch Linux.

Xv kimenetet használtam én is, a directfb csak telepítést nehezítő függőség volt.
Nálam P4 osztályú volt a tesztgép, mint azt a cikk elején is kiírtam, 2-3GHz közti, egymagos gépen mérve.
(Nem Pentium 3 és Pentium M, mert utóbbi is csak P3 magos)
Az intel vga teszt sincs még kész, egy hete szinte kizárólag nvidiáról beszéltünk a nyitó topicban.
De a lényeg az, hogy elkezdtél mérni és kísérletezni, gondolkodni.
-
"Attempting to crack SpeedLock can damage your sanity"

A Pentium M legfeljebb P6 mikroarchitektúra, a sorban a Pentium 3 előzi meg és a Core Duo követi.

(vagyis se nem Pentium Pro, se nem Pentium 2 vagy 3 csak azért mert ugyanarra a mikroarchitektúrára épül, kevered a Pentium 3M-el, ami egy Pentium 3-as mobilprocesszor).

A Pentium 4 Netburst mikroarchitektúra első és utolsó képviselője.

Az 1.2 Ghz-es Dothan magos Pentium M teljesítménye egy 2.4 Ghz-es Pentium 4-nek felel meg.

"They evolved from the core of the last Pentium III–branded CPU by adding the front-side bus (FSB) interface of Pentium 4, an improved instruction decoding and issuing front end, improved branch prediction, SSE2 support, and a much larger cache."

http://en.wikipedia.org/wiki/Pentium_M

Nem keverem a P3M-mel.
A Pentium M egy P3-származék core, kiegészítve a P4 vonal számos újításával,
és optimalizált hő/energia-gazdálkodással.
-
"Attempting to crack SpeedLock can damage your sanity"

Quick and dirty, szó szerint!
(de a hét bájt tényleges cseréjétől eltekintve ez nem két perces munka volt, hónapok vannak mögötte)
Van egy régi mondás, öreg vasas szakiktól hallottam:
"Egy csepp olaj a megfelelő helyre néha többet ér, mint hat hülye lakatos!"

De képzeld el, mi lesz, ha ezen felbátorodva több százan esnek neki gépi kódban
optimalizálási lehetőségeket keresni a jelenlegi -sokszor nagyon lusta- alkalmazásokban?
-
"Attempting to crack SpeedLock can damage your sanity"

Rendben, ASM-ben (adott architektúrára) lehet implementálni meglévő dolgokat, lehet adott kódot újrafordítani adott fordítóval, adott paraméterekkel, adott architektúrákra. Lehet a kódot módosítani, algoritmusokat újraírni. Sokféle optimalizálási lehetőség van.

De itt most kifejezetten és kizárólag annyi történt, hogy egy MPlayer binárisban kicserélted a függőségeket (hexa editorral), hogy a libx264.so.64 helyett a libx264.so.85-t használja.

Több hónapnyi munka helyett csinálhattad volna azt is, hogy:

1. Fogod az MPlayer [SVN r27637] (2008.09.18) forráskódját és újrafordítod.

2. Softlinket használsz, libx264.so.64 -> libx264.so -> libx264.so.85.

Az első lépésnek azért nincs értelme, mert az az MPlayer (27637) nem gyorsabb a mostaniaknál (30818).

Lehet, hogy én fogalmaztam rosszul?
Nem a 7 byte patch tartott hónapokig :)
hanem a megfelelő bináris és a megfelelő libek/kodekek összehangolása megfelelően kikönnyített rendszeren.
Az újrafordítás az adott sorszámú src csomagból ezen a rendszeren nem megy, a forrás jelentősebb módosítása nélkül.
A jelentős módosításokat pedig el kellett kerülni.
A softlink megoldás itt is ment egy darabig, kicsivel feljebb részletesen leírtam, véglegesítéséhez a legegyszerűbb volt ez a patch.
(ha ez gáz, akkor se diff-et, se delta rpm rendszert ne használj, technikailag az is így működik)

Gyorsaság tekintetében világosan leírt, adott tesztkörülmények közt született eredmény,
egyetlen szóval sem mondtam, hogy a te Arch linuxodon mértem volna azokat.
-
"Attempting to crack SpeedLock can damage your sanity"

Tehát akkor azért nem a libx264.so (a mindenkori legfrissebb libx264-re mutató softlink), hanem a libx264.so.85 a függőség a módosított binárisban, mert az optimálisabb teljesítményt nyújt a rendszereteken, mint mondjuk a libx264.so.88 (jelenlegi legfrisebb libx264)?

Nem kötekszem (tényleg), csak érdekel.

Mármint a .64-et .85-re.

Az libx264 egyébként a x264 csomag része, enkódolásra való.

A dekódolást (azaz lejátszást) az FFmpeg libavcodec H.264 dekódolója végzi.

A libmpcdec a Musepack dekódere, konvertere (egy audió formátum, MPC kiterjesztés).

Most, hogy ennek utánnanéztem már nem értem mitől lenne gyorsabb az MPlayer H.264 lejátszás frissebb libx264-el és libmpcdec-el.

Más szóval a "patch" nem csinál semmit.

Pontosan. A libx264 egy encoder, nem codec.
Az x264 lejátszásért a libavcodec h264 dekódere felel...
(ezért röhögtem magamban olyan jót, amikor feljebb valaki "kijavított", hogy az nem h264, hanem x264...)
A patch csak azért kell, hogy a programot telepíteni lehessen.
A sebesség az összes -dekódolásban és futtatásban- komponens megfelelő összeállításán múlik.
Ahogy már százszor leírtam: a megfelelő bináris, a megfelelő "körítéssel", és a megfelelő alapokon.

Egyébként közben azt találtam még, hogyha a csomagunkban lévő /usr/bin/hdmkv.sh scriptben
az mplayer paramétereinél a hangkimenetet openal-re változtatom, tovább csökken a terhelés.
-
"Attempting to crack SpeedLock can damage your sanity"

Akkor sok sikert, én ugyanígy kísérleteztem a Pentium M processzoros notebookon, többféle komponenst próbáltam ki, végül a xorg-server 1.6-hoz patchelt xf86-video-intel 2.3.2 EXA-val, KMS-t nem támogató 2.6.27-es kernellel (amit aktívan fejlesztenek, többek között az ext4 is belekerült) bizonyult messze a legjobb választásnak.

Már csak azért is, mert a 2.6.27 után a 2.6.34-rc1 az első kernel amivel megy a videókártya (UXA-val és KMS-el, amik nem opcionálisak).

Mindez mégsem jelenti azt, hogy a HD tartalmak nagy részét le fogod tudni játszani egymagos processzoron, postprocessing-re meg végképp nem marad kapacitás.

Legközelebb meg óvatosabban a közleményekkel, lelkesedés ide vagy oda.

Ugyanazt a kernelt használjuk?
Elméletileg ez lesz a hosszú karbantartású sorozat alapja.

Postprocessingre nem fog maradni a teljesítményből, de nem is a lehetetlen volt a cél.
A lejátszás megy.

A "legközelebb óvatosabban..." kezdetűt viszont udvariasan,
de kikérem a magam, és a fejlesztők/tesztelők nevében is.
(Én is voltam fiatal ifjú titán, de az már nagyon régen volt.)
-
"Attempting to crack SpeedLock can damage your sanity"

"Ugyanazt a kernelt használjuk?"

Felteszem, notebookon 2.6.27.45, a Pentiumon 2.6.32.10-et (az asztalin meg inkább Windows 7-et).

"A lejátszás megy."

Alacsony profilú 1080p-s H264 tartalmak esetén talán.

"viszont udvariasan"

Te írtad, hogy egy javított régebbi MPlayer, mire közétettél egy lényegében módosítatlan MPlayer-t.

És ez mint hír jelent meg a főoldalon, mintha bármiféle hírértéke lenne, eredményként feltüntetve a nagy semmit.

Tudom, hogy nincs jogom hozzá, és, hogy kritizálni a legkönnyebb, de nem alaptalanul teszem.

Tehát, a közleményekkel a jövőben megfontoltabban.

http://hup.hu/node/84450#comment-979655

Itt indult az mkv történet, ssa2 fórumtársunk adta az ötletet,
és egy linkben adta hozzá az általa jó alanynak gondolt mkv tesztfilmet is.

Töltsd le, nézd meg.
Itt várlak a véleménnyel.
-
"Attempting to crack SpeedLock can damage your sanity"

Letöltöttem, megnéztem.

Egy 1080p-s H.264-es videó 384 kbps AC3-as audióval (a hangsáv CPU terhelése gyakorlatilag semmi).

A Pentium M 1.2 Ghz csak skiploopfilter-el, hard framedrop-al és audió-videó szinkronizációval vitte 100% CPU használat mellett.

A Pentium 3 1.4 Ghz még azokkal se.

Ezt a videót egy 2.4 Ghz+ egymagos Pentium 4 processzor már lejátsza optimális körülmények között.

Próbálkozz DTS-ES hangsávos videókkal.

Az MPlayer skálázható, de ennek felismerése és a manualból szedett kapcsolók alkalmazása még nem számít eredménynek.

Nem is a manualból szedett kapcsolók alkalmazása volt ebben a munka,
ezt nem állította senki (csak te), hanem több év MPlayer SVN "terméséből"
megtalálni a lehető legjobban sikerült forrást vagy binárist,
és azt teljesítményesés nélkül, lehetőleg plusz növekedéssel, működőképesen
és hibamentesen beilleszteni az adott rendszerbe.
Nincs itt vége a történetnek, mert közben zajlik az adott sorszámú forráskód
"lefogyasztása" kimondottan mkv player célra.
(Csak az marad benne, ami mindenáron szükséges hozzá. Ha sikeresen lefordul,
akkor elkezdődik az akkor már kis méretűvé vált kód vizsgálata,
optimalizálása,stb...)

-
"Attempting to crack SpeedLock can damage your sanity"

Röhöghetsz nyugodtan, de az akkor sem az.
Most nem szeretném sorolni a különbségeket, mert rengeteg. Profi videós körökben semmire sem becsülik az x264-et, mivel ez "csak egy implementáció" és maximum nagyon hasonlít a hivatalos szabványra. A másik, ehhez hasonlóan népszerű topicban tárgyalt wmvHD alatt is általában az MS VC-1 nevű implementációját kell érteni, ami szintén nem h.264. Attól, hogy a garázsban te egy Ladát BMW formájúra kalapálsz, még rohadtul nem lesz BMW-d. Ennyi.

A másik gond, hogy szerintem valami baj van a hozzáállásoddal. A distrib eredményeit nem vitatom, ebből a szempontból tök lényegtelen. Olyan ez az egész jelenség itt, mintha mindenáron meg akarnád védeni az igazad, mintha bárki bármit mond, akkor is te vagy a király, mert hexában programozol és ismered a decibelt. Ez lehet, hogy így van, de ettől még nem kell ilyen fellengzősen, ilyen magasról kommunikálni. Ezzel csak hírhedt, de nem híres leszel, ami szerintem nem lehet cél, ha valamit képviselsz is.

Az x264 egy H.264/MPEG-4 AVC video encoder, vannak más encoderek is, mint a DivX Plus HD vagy a ProCoder.

Lehet vitatkozni melyik implementálja megfelelőbben a H.264 szabványt, de lásd:
http://en.wikipedia.org/wiki/H.264#Software_encoder_feature_comparison

Ezek szerint az x264 teljeskörű, és a legszabványosabb H.264 encoder.

A WMW HD nem H.264, hanem VC-1 WMV3 implementációjának Main Profile @ High Level beállítás mellett enkódolt formátuma.

A wmvHD és az MKV két külön téma a cikken belül, nem az mkv konténerben volt wmv tartalom...
A wmvHD adta itt a fórumon valakinek az ötletet, hogy nézzünk meg egy szokványos mkv fájlt is.
(nem keverte itt senki a Ladát BMW-vel, te maradhattál le a történet elejéről)

A ténylegesen profi videós körökben is ismert az x264,
a MainConcept GmbH jópár éve mesteri fokig gyúrt belőle kereskedelmi kodeket,
meg is vette őket a DivX Networks, tokkal-vonóval, mert kellett a kodek és a tudás.
-
"Attempting to crack SpeedLock can damage your sanity"

A symlink miert nem volt a vegen jo?

Egyebkent pedig, ha ezt mar az elejen elmondtad volna, nem ugrottak volna ennyien neked. Nem mindenki szeret am hexaeditorokban turkalni a mai vilagban (en sem).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

"nem mindenki szeret hexa editorokban túrkálni a mai világban"

Ha Alexander Fleming is a kényelmi szempontok szerint gondolkodott volna,
akkor simán betette volna a sterilizálóba azokat a bizonyos véletlenül megpenészedett petri-csészéket. :)

A symlink azért nem volt jó, mert első nekifutásra a csomagkezelőnek nem teljesen nyerte el a tetszését a dolog.
A symlinkeket tartalmazó rpm csomag szépen települt, de az mplayer telepítésénél mégis jelentkezett függőségi hiba.
A leggyorsabb megoldás a patch volt, ez egyetlen csomagban megoldott mindent.
(közben a háttérben párhuzamos munka is fut, a hivatkozott "erős build" mplayer forrásának fogyasztása,
úgy, hogy csak az mkv+ffh264+lehetséges hangsávok kodekjei és xv illetve néhány hangkimenet támogatása
maradjon meg, a többi kuka. Így keletkezik egy jó és karcsú alap a későbbi mkv-player smirglizéshez)

-
"Attempting to crack SpeedLock can damage your sanity"

En azert tovabb hajszoltam volna azt a symlinkes megoldast, a jovoben ugyis meg kell oldanotok azt a problemat, hidd el. Ne a lustasag/sebesseg vezessen, mert abbol semmi jo nem sul ki. Szerintem ez a binaris patchelos moka tenyleg nem a legjobb megoldas, ha megharagszol erte, akkor se. Az rpm van olyan jo, hogy akar postinstall scriptbol is lehet symlinket gyartani, de van millio es egy masfele megoldas is, pont a binaris patcheles az, amit kerulni kell, foleg azert, mert ha azok a libek megint frissulnek, megint patchelni kell a binarist - holott egy symlink eleg lenne.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Nem lesz szükség sem további vitára, sem a symlinkekre...
Közben véget ért a megadott mplayer kód lefogyasztásának első fázisa,
(mkv player fork, csak a feladathoz szükséges alkatrészek felhasználásával)
ehhez már nem kell a fenti 3 régi függőség (sem).
A patch egy átmeneti állapot volt, de nem tudtam előre,
hogy mikorra lesz kész megőrzött minőségben és lefordítható
állapotban az "mkv player" kódalapja.
Lefordult, első próbakörök megvoltak,
1920x1080 teljes felbontás mellett (nem lowres, stb),
csak a fast=1:skiploopfilter=all opciókkal xv+alsa vagy xv+openal kimeneten
~2-2,5GHz singlecore CPU és 256MB 400MHz DDR1 (vagy ezzel eq. teljesítményű)
alsó határértéktől felfelé eddig jó.
Nincs vége.
Folyt.köv.
-
"Attempting to crack SpeedLock can damage your sanity"

Ebben egyetértek, hosszú távon biztos, hogy jobb és kényelmesebb megoldás, mint binárist hekkelgetni. Nem vagyok RPM alapú linuxok szakértője, nem is nagyon használom, ha nem muszáj, ezért egy kérdés: elvileg egyszerűen kikalapálható eCaffee által felvetett probléma, miszerint telepítés után voltak még függőségi gondjai? Mert ha igen, segíthetnél neki benne, s akkor megszűnne az itt 3 napja folyó vita, hogy ez most így jó-e, vagy sem.

( zsoltee | 2010. 03. 23., k – 00:05 )

Mari néni a könyvtárban rádugja a kiselejtezett gépre az usb-s blurayt és tolja 1080p-ben a Titanic-ot?

Vagy megint én vagyok olyan korlátolt, hogy nem látom a célcsoport igényét?
Persze mint garázstuning, elismerendő teljesítmény ;)

Már jó ideje nem vagyok egyedül, lassan gyarapodik a segítő tábor, közreműködők jönnek,
debian/ubuntu port készül a dolgainkból, és együttműködések is indulnak már.
Hazai Ubuntu körökben már elindult -nem tudom, hogy már Susie-hatásra, vagy attól függetlenül is-,
egy hasonlóan könnyű, gyors változat készítése.
Nem világmegváltás készül, csak bedobtam az állóvízbe egy kavicsot.
-
"Attempting to crack SpeedLock can damage your sanity"

En meg mindig amondo vagyok, hogy nem feltetlen a 1080p kihajtasa a cel, viszont manapsag egyre kevesebb olyan minosegi film toltheto le, ami nem ilyen formatumban keszult. Es ez a trend a BD elterjedesevel csak fokozodni fog. IMHO egyszeruen a filmnezes lehetosegenek megadas a cel.
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

Egy nappal ezelőtt még azt hittem, hogy a Susie kis csapata elvesztett egy nagyon józan vélekedésű,
és jó szándékú támogatót, és örülök, hogy nem így történt!
Tartozom egy bocsánatkéréssel, (neked is, és többeknek is)
de nem teríthettem ki a kártyákat addíg, amíg néhányan gondolkodni
és kísérletezni nem kezdenek. Most már biztos lehetek benne,
hogy többen is fognak kűzdeni például az általad idézett lehetőségért is.
-
"Attempting to crack SpeedLock can damage your sanity"

( honorshark | 2010. 03. 24., sze – 17:33 )

Amugy hogy merted azt a Win-es eredmenyt? DXVA meg legujabb ffdshow + vadonatuj mpc-hc? Ketlem hogy a Linuxos kevesebbet enne amugy, nemreg probaltam meg. (Na meg ha ez amit csinaltal bejon, akkor fogom es winre forgatom a buildot, ranyomom ugyanezt a 'hekket' es rakok ra smplayer-t.. mi a kulonbseg? Ismet csak alacsonyabb terheles ... nem?)

Nem mért Windows alatt.

A hack, azaz a libmpcdec (Musepack converter), libx264 (H264 encoder) és libdirectfb (DirectFB) legfrissebb változataira linkelés nincs hatással a CPU terhelésre, ezek ugyanis nem érintik a dekódolást, azaz lejátszást.

A hackre a közleményben leírtakkal szemben a függőségek feloldása miatt volt szüksége (használhatott volna softlinket).

Jo de erted mire ertettem... megkene probalni. Megprobalom majd az atom-os vasamon hetvegen. Most mar kivancsi vagyok. Intel van benne, DXVA-t tud, sajat mpc packom felrakom, hatha bikabban birja. Vegulis CoreAVC -vel barmelyik atom-os / ht-s gepen vagy gyengebben is lemegy a HD -s MKV (tudom container nem kell a papolas mar)

Nekem nem lassabb Windows-on a videólejátszás Pentium M és Intel 855GM rendszeren (sőt, gyorsabb, mint a disztribúcióval érkező MPlayeren).

Az Athlon II X2 240, Radeon HD 4200 párost meg nem tudom / nem akarom tesztelni Linux alatt, mert a videókártya nem támogatott (bár a két nyílt forráskódú és egy zárt driver közül valamelyikkel lehet, hogy működésre lehetne bírni, de a hardveres videógyorsítás kétlem, hogy menne)

"megkene probalni. Megprobalom majd az atom-os vasamon hetvegen. Most mar kivancsi vagyok"

Megfogant a gondolat, és ez jó. Kételkedni kell és kísérletezni,
a legrosszabb ami történhet, hogy nálad -adott hardveren/szoftveren- nem megy jobban.
-
"Attempting to crack SpeedLock can damage your sanity"

Az a 15 EUR (vagy USD) nem összeg egy tényleg jó kodekért,
én még a MainConcept X264-re is kíváncsi lennék, ha tudnék szerezni próbára egyet.

Még valami, ami fontos: napok óta mondják páran, hogy a közölt -lavcopts lowres=1... opciótól húdeborzasztó képet láthatok,
de valahogy nem tünt fel, pedig nagyon gyanús volt...
ma jöttem rá, hogy a fenti MPlayer buildben nem működik a lowres, ha meg van adva
AKKOR IS teljes felbontásban dekódol, a tesztfilmnél teljes 1920x1080 ment...

Szóval, nyugodtan módosítható a csomagban lévő /usr/bin/hdmkv.sh megfelelő sora az alábbiak szerint:
mplayer -fs -really-quiet -vo xv -ao alsa -vfm ffmpeg -lavdopts fast=1:skiploopfilter=all $file

illetve alsa helyett az openal még jobbnak bizonyult, kevesebb a terhelés,
~2-2,5GHz singlecore CPU és 256MB 400MHz DDR1 (vagy ezzel teljesítményben egyenértékű vas)
a körülbelüli határérték...

-
"Attempting to crack SpeedLock can damage your sanity"

Nagy nehezen itt vagyok, órák óta nem volt errefelé sem kábelnet, se mobil térerő.
(mindkettőt a "gsm-toronyszoftver-frissítő" szolgáltató biztosítja...)

"Amugy hogy merted azt a Win-es eredmenyt?"
Win eredményt nem mértem, a Microsoft közölt egy hivatalos minimális hardver elvárást 1080p wmvHD-hez. (WinXP v. újabb, 3GHz P4, 512MB)
Ezt übereltük Linuxon 2/3 CPU, és 1/3 RAM terhelés felhasználásával, 1080p wmvHD referencia demo lejátszáskor.

Az MKV (és benne X264) ügy már eközben jött, mert egy olvasó felvetette, hogy mi lenne, ha tesztelnénk azt is,
hátha sikerül valahogy az adott hardver-szoftver tesztkonfigon.
(1998MHz Athlon XP 2400+ és 256MB DDR1 éppen a határeset,
GF6200 VGA-val, 190-es nvidia driverrel. A szoftver Susie beta,
és a cikkben megadott linkeken letölthető mplayer+w32codec)
-
"Attempting to crack SpeedLock can damage your sanity"

( Qju | 2010. 03. 25., cs – 03:42 )

Előre bocsájtom, hogy (töbnyire) csak read-only felhasználója vagyok a HUP-nak. Annak ellenére read-only, hogy már-már "ős hupper" -nek számíhatok. A reggelést idejét figyelembe véve mindenkép. :)

Nekem tetszik a Susie. És tetszik az a lelkesedés is amivel eCaffee dédelgeti a projektet.
Persze nekem tetszik pl: a Puppy, BrowserLinux is.
A 80mm-es mini CD-re vagy a 64MB-os USB-re írható live rendszerek láttán is különös izgalom fog el :)

Szeretem ha a gépem pl: a GRUB Menu-vel fogad. :D

Mondjuk annak kiváltképp nagyon tudnék örülni, ha az egyszerű grub is grafikus lenne és a gafikát nagyon könnyen lehetne csereberélni.
Függetlenül a telepített OS-tól és a vas erejétől.

( az ubuntu 9.10 és a Linux Mint 8 az igen-igen erőforrás igényes grubja miatt bukott el e gépemen ; Celeron III 800Mhz, 512MB, WD 250GB )

* te tudod hogy qju vagyok ?

A GRUB nem erőforrásigényes, csak egy boot loader és végképp nem grafikus.

"az egyszerű grub is grafikus lenne"

Attól egyszerű, hogy nem grafikus, felesleges a boot loaderbe egy kernel ami kezeli a grafikus megjelenítést.

"az ubuntu 9.10 az igen-igen erőforrás igényes grubja miatt bukott el e gépemen"

Az nem a GRUB, hanem már maga a bootolás, ami helyett egy grafikus splash-t mutat a rendszer.