MPlayer 1.0rc3 - "Godot has arrived"

MPlayer

2007. október 7-én jelent meg az MPlayer 1.0 második kiadásra jelölt verziója. Az rc3-ra több mint két és fél évet kellett várni, de végül ma megérkezett.

Az rc3 eredetileg egy évvel ezelőtt érkezett volna, így már azelőtt elavult, hogy kiadták volna. Disztróknak feltehetően hasznos lesz ez a kiadás, de a bejelentés szerint általános felhasználásra jobban megfelelnek az aktuális Subversion snapshot-ok. Részletek a bejelentésben.

( NagyZ v | 2010. 05. 30., v – 19:29 )

"Godot has arrived" - ezen hangosan felsikitottam :D

( bastya_elvtars | 2010. 05. 30., v – 19:43 )

"általános felhasználásra jobban megfelelnek az aktuális Subversion snapshot-ok"
Akkor mi az értelme a release-nek egyáltalán? :-)
"no video codec le a win32vel", de "Gentoohoz lehet meg tul fiatal vagy"

anno voltak olyan featurek amik annyira bugosak/felkeszek voltak, hogy nem volt alapbol bekapcsolva. de release-be bekapcsoltuk, hogy teszteljek a juzerek.

mostani rls szerintem user/distrokeszito nyomasara lett kiadva a sok "miko' lesz ma' rillizzz???" miatt. nem hiszem, hogy (sokban) elter az aktualis svn-tol.

A'rpi

"anno voltak olyan featurek amik annyira bugosak/felkeszek voltak, hogy nem volt alapbol bekapcsolva. de release-be bekapcsoltuk, hogy teszteljek a juzerek."

Ez igy elsore elolvasva nagyon rosszul hangzik. Ize, a gond az, hogy masodikra is.
-- 


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

( arpi_esp v | 2010. 05. 30., v – 22:49 )

lol, ilyen se volt meg, hogy mplayer rls-rol a hup-on ertesuljek eloszor ;)

azert tervezik mar 1 ideje:
- rc3: "BikeshedCounter" March 27, 2009
+ rc3: "BikeshedCounter AKA Godot" May 30, 2010

hmm, ez kezd erdekes lenni:
Date: Fri Mar 27 20:13:50 2009
New Revision: 29073
Log:
Create 1.0rc3 release branch.

szoval ez az rc3 nem is friss svn-bol van hanem tobb mint 1 eves branchbol, amibe a log szerint csak par kisebb fixet backportoltak... rotfl.

A'rpi

en is hangsoan rohogtem... csak aztan belegondoltam, hogy a disztributorok nagy resze ezt nem fogja felfogni, csak azert is pakolja a "friss" release-t a repoba majd :/
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

( marcabru | 2010. 05. 30., v – 23:08 )

Tudom, nem vagyok hivatott a belepofázásra, de: olyan nehéz lenne egy úgy-ahogy leforduló svn-snapshotot kinevezni 1.0-nak, majd ami bug van benne, azt az 1.1-re kijavítani? Mi értelme van annak, hogy a stabil kiadás több éves állapotot takar, és a júzerek nagy része (aki simán a csomagkezelőből telepíti) ezt használja?

talan az, hogy ugy fejlodik egy projekt, ahogy 2010-ben fejlodnie kell, es nincs bezarva fejlesztest (vagy akar bugfixeket) akadalyozo felesleges freeze-ek koze? Es mplayernel nem "ugyahogylefordulo" snapshot van, hanem a topbbi ilyesmi projekttel ellentetben a kommitokat tudtommal tesztelik 2-3 napig, mielott bekerul svnbe. Nem az mplayernek kene maskepp gondolkodnia, hanem a disz tributoroknak
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

megfigyelhetted mar, hogy honorsharkkal tobbmidnenben nem ertettunk egyet :D Bar az mplayeres dolgokban asszem igen
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

"Nem az mplayernek kene maskepp gondolkodnia, hanem a disz tributoroknak"

Ez itt nem gondolkodás, inkább kommunikáció kérdése. A "release", az "unstable", a "snapshot" olyan fogalmak, amikkel a fejlesztők és a disztró csomagolói egymással kommunikálni képesek. Az mplayernél úgy tűnik máshogy értelmezik ezeket (pl "a kommitokat tudtommal tesztelik 2-3 napig, mielott bekerul svnbe", a release pedig nem cél, hanem "akadályozó és felesleges"). Miért változtasson a gyakorlatán egy disztribúció, ha egyszer a többi 5232 csomagnál jól működik a stable-unstable megkülönböztetés? Mi lenne a helyes teendő? Az Ubuntu 10.04-be a 20100420-as svn kerüljön bele? Vagy a 20100422?

igen, ha az Archnal es a Mintnel es a Slackware-nel tudnak egy ilyen minimalis figyelmet szenteléni a fejlesztok velemenyere, akkor az Ubuntutol is elvarom
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

Nagyon sokáig magam fordítottam az svn-t, de azért most már belátom, hogy sokaknak tényleg opció az svn használata. Meg egy stabilnak szánt rendszerre sem lehet csak úgy nem támogatott repókat felrakni, mert súlyos kockázatnak tesszük ki a rendszert.

Egyébként nem panaszkodom, hiszen ingyen van, lelkesedésből fejlesztik. Csak rossznak tartom, hogy a felhasználók többsége 2-3 éves állapotából ítéli meg az MPlayert, mert nincs ideje, lehetősége másra. Gondolok itt a DVD-menük lejátszására, ami azért nemrég került bele...

Ugyanez a véleményem a wine projektről is. De ők legalább most végre megjelentetik a wine-1.2-t. Előtte ott is két évig a disztrókban ősrégi változat volt, miközben az instabilból már régen lehetett volna új release-t csinálni.

( ShiZy | 2010. 05. 30., v – 23:30 )

Nekem csak egy naiv kérdésem lenne: milyen ütemben halad az MPlayer fejlesztése? Látszólag az MPlayer háza táján elég nagy csönd honol, kívülállóként nem igazán látom az aktivitást. A lassú kiadási ütemterv nem is zavarna, nincs is semmilyen problémám, egyszerűen csak nem igazán követem a háttérben történő eseményeket, pusztán kíváncsiság vezérli kérdésem.

(Már csak azért is, mert nem igazán találok egy rendes lejátszót. VLC majdnem jó lenne, de annyira bugos és sok vele a probléma, hogy lassan az idegeimre megy. Alap MPlayer felületileg kicsit puritán, a ráépülő frontendekkel (pl.: SMPlayer) viszont nagyon szimpatikus lenne, de valamiért egyik sem az igazi. :/ Ha valaki tud ajánlhatna valamit.)

linuxra right click open with mplayer, midnenfele gui nelkul. Se kmplayer se smplayer se gnome-mplayer se semmi ilyesmi nem valt be, mplayer az nekem "parancssoros" lejatszo marad. Ezt a disztributoroknak probalhatod elpofazni, még a Debian meg a Suse sem kepes GUI-mentes mplayert szallitani, ami még egy ujabb ok arra, hogy forrasbol forditsd a latest snapshotot (kiveve Archon, Minten meg Slacken, ott svn-est szallitjak).

Az mplayer az a projekt, ahol annak ellenere, hogy nincsenek release-ek, annak elenere igenis megy a fejlesztes, mar Inteles meg Atis hardware gyorsitas commitok is voltak, mig a xine még a vdpau implementalasaval is kuszkodik azota is. Az mplayer a legjobb pelda arra, hogy mennyivel jol is tud fejlodni egy rolling projekt valojaban. Ennek ellenere pl kernelbol vagy KDE-bol nem orulnek ilyen szintu rolling release-nek, de egy filmlejatszonal tenyleg eleg a commitot 2-3 napig tesztelni
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

+1
Feliratok tologatására, feliratok váltogatására, vdpau gyorsításra, av-sync beállítására (MPEG-TS-nél kell, sajna) az mplayer-nogui a legjobb.
Nekem egy újabb változat van, mint ami a lucid tárolóba bekerült (Version: 3:1.0~rc3+git20100526.98a8126-0ubuntu1~ripps1~lucid), ez gyorsabb.
Az állandó dolgokat meg config fájlban rögzítettem.

Egyedül a DVB-re nem tudok jó megoldást, mert a HD-t tök jól lenyomja, de az SD-knél baj van a -mc paraméterrel, így ezeket a VLC-vel szoktam nézni.
Rögzíteni is mplayer-rel szoktam (dumpstream), ami egyben timeshift-re is lehetőséget biztosít. Számomra megfelel.
A legnagyobb bajom az, hogy az ffdshow-hoz hasonló, elég szerteágazó postprocessing nincs még a vdpau alá rakva, de az idő talán majd ezt is megoldja.

totem egy vicc. Foleg a gstreamer alatta mint filmlejatszo backend. Xine akkor mar egy fokkal hasznalhatobb filmlejatszasra (kaffeine)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)

> csak ugy jonnek a baromsagok! :)
es te is azt irsz! :)

libavcodec != ffmpeg. az csak 1 kis resze, amiben a codecek vannak. ezen kivul meg eleg sok minden kell egy lejatszohoz, az egyik legfontosabb (es ezen dol el a hasznalhatosaga, megbizhatosaga) a demuxerek. ez pl. az mplayerben sajat van, nem az ffmpeg-et (libavformat) hasznalja, bar azt is tudja, ha nagyon akarod. gstreamernek is sajat demuxere van, es eleg gagyi.
tovabba az audio, video output driverek, iletve az a-v szinkronizalas sem elhanyagolhato, ez is minden playerben sajat, vagy esetleg SDL-t hasznalnak.

A'rpi

( mapee v | 2010. 05. 31., h – 08:27 )

gentoo stable : 1.0_rc4_p20091026-r1
gentoo testing : 1.0_rc4_p20100506

Apple MacBook C2D 2.2Ghz 2x2G Intel X3100

( csabka v | 2010. 05. 31., h – 09:47 )

Sima video megjelenítéshez mindegy mi... ami éppen lejátsza (mplayer, vlc, totem), de film nézéséhez csakis XBMC (http://xbmc.org/)
A legszimpatikusabb benne, hogy a tömörített fájlt (még ha 50 dbra tördelt) ha média akkor a tartalmát mutatja, majd röptében kicsomagolva játsza le (avi vagy akár iso -t is)
Ráadásul, ha újraindítom vagy később folytatom ugyan ott folytatja ahol abbahagytam (annak ellenére hogy tömörített fájlban van).

Lehet, hogy mlayer vagy egyéb backend van mögötte, de mint felület kiváló.

Apropó az mplayer tud tömörített állományból közvetlen lejátszani?

pl torrenten letöltött "házi oktató" :-) filmek darabolt rar-ban vannak, s ha szeretnék visszaadni a "közösségnek" is akkor nem törlöm le a letöltött fájlokat.
Kicsomagolva és tömörítetten egyidejűleg tárolni a gépen több helyet foglal, ráadásul a kicsomagolás plusz idő amikor megnézni 1x vagy 2x fogom megnézni...felesleges.

Így, ha van mód, hogy ne kelljen kitömörítésre várni, majd lejátszani, s törölni a kitömörítettet azt örömmel venném, s megköszönném.
Nem tudom mennyi meló, de sokszor jól jönne ilyen feature (szerintem másnak is).
Ubuntuban jobbklik rar-ra, play content with mplayer ;-)

MPlayerben volt unrar támogatás valamikor.

FIXME: mire épül (Roschal-féle hivatalosra vagy az urarlib nevű abandonware-re ami 10 évnél újabb formátumot nem ismer) ill. mennyire tartják karban.

szerk:
MultimediaWiki szerint:
How can I play movie in rar? 

unrar p -inul movie.part01.rar |mplayer -noidx -

xbmc-re írtam, hogy tudja... vlc-t nem tudom.
Az XBMC beépített filetallozójában, amikor olyan mappába lépek be ahol tömörített darabolt fájlok -akár rar akár zip- van, aminek a tartalma iso vagy avi (vagy egyéb media), akkor már eleve csak a médiát látom "elrejti" a sok felesleges állományt (nfo, sfv, tömörített fájlok) és egyszerűen csak rábökök hogy megnyit...
- lehet benne seekelni,
- dvd-nél chapterekre ugrani stb
- nem kell várni a kitömörítésre egyből játsza (2-10 sec delay max lehet de elhanyagolható) .

Azt hogy milyen megoldással csinálja nem tudom, Pontscho biztos tudja.

nem is azért írtam :-) hanem inkább saját tapasztalatomat írtam le, hogy milyen apróság miatt döntöttem egyik vagy másik mellett... (még úgy is hogy nagyságrendekkel több memóriát igényel, s indulási idő is több valamint robosztusabb kezelőfelülete van, de megszokható...)

Amúgy előtte csakis mplayer-t használtam Ubuntu és Windows-on egyaránt.
Így is amikor csúszik a felirat vagy épp hang akkor marad a kicsomagol és mplayer, mert lehet billentyűkkel szinkronba hozni lejátszás közben, ami szuper dolog :-)

azt nem értem ez miért a lejátszó dolga lenne

a windows is nehezen kezeli még a zipet is, hiába olyan mintha mappa lenne, mégis szív vele az ember ha nem tudja hogy az biza zip (pl egy fájlt egy program megnyit, az már nem látja a következőt, pedig csak olvasható igazi mappa ként nem lenne vele gond)

azaz a fájlrendszerre kellene valami, mint ahogy az iso-t win és linux alatt is kényelmesen fel lehet csatolni, de a zip-et és a többi tömörített pedig még csak nem is láttam

(ps: azt értem hogy "solid" esetben nehéz lenne seekelni, de pl zipnél megoldható lenne és solid esetben is opcionálisan pl egyszer temp-be kitömörtené.. )

valóban... jól hangzik, bár az iso egy fs kontainer a zip pedig tömörített...
Gondolom fuse-n keresztül létezhet "zipfs" :-) csak kérdés, hogy mennyire működőképes...
Lehet, hogy az XBMC is ilyesmit csinál, hiszen beépített filemanager-e van ami akár meghívhatja így is, ennyire nem ismerem.

Ez a darabolt rar egy idiotasag, dunaba kene loni az osszeset, aki igy tesz ki dolgokat. 2010-ben mar senki nem torrentezik olyan fajlrendszerrol, ami nem kepes 4G-t eltarolni egy fajlban. Es nehogy mar a filmlejatszo alkalmazkodjon minden hulyeseghez.
-- 


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

A 64 bites file offset (4 GB feletti fileok) támogatása még 2007-ben is probléma volt 32 bites rendszereken, az akkori disztribúciók általában letiltották a serverek akkoriban kísérleti largefile opcióját fordításnál.
Tehát a filerendszeren megvolt a nagy file, de se ftp-n, se http-n, se smb-n nem tudtad szolgáltatni a daemonok kézi újrafordítása (és kockázatvállalás) nélkül.

A másik gond az átviteli hiba, ami miatt az egészet kitalálták még a floppy korszakban. Azért daraboltak, hogy ha valamelyik rész hibásan jön át, ne kelljen újra letölteni az egészet.

szerk: kicsit átírtam, jobban körbenéztem, nem akarok FUD-olni

Hmm... ennyire nem vagyok otthon a warezbe, szoval akkor megkovetlek.

Ez esetben a torrentfeltoltok a hibasak, hogy nem egyesitik a fajlokat megosztas elott. Meg mindig ugy gondolom, hogy ne a lejatszo idomuljon az ilyesmihez.
-- 


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

Azzal nem élek. Viszont Debianon sz.ptam vele eleget...
Apache-ban amúgy a 64 bites offset csak 2.2-től default 32 biten, 2.0-nál configure opcióval lehetett bekapcsolni (amit a debian/redhat nem tett meg), azelőtt meg nem támogatták a fő forrásban. A FreeBSD saját patchet tartott karban?

Az FTP servereknél, sambánál hasonló volt a "törzsfejlődés" az elmúlt években... szerk: a kernel is csak valamelyik 2.2.x verzió óta támogatja.

Akkor probalj meg raguglizni a "bittorrent streaming" kulcsszavakra, es probald meg osszehozni a darabolt fajlokkal.

Nem is tudom, hogy amit csinalsz az rohelyes, szanalmas, vagy csak megint elgurult a gyogyszered. De lehet, hogy edzodnom kell, most egy honapig HUP-mentes helyen voltam.
-- 


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

mire gondolsz pontosan? hogy a warez scene az nem a bittorentes pistikekrol szol? vagy ezt nem tudtad?
lehet elobb streameltem elosztott rendszerrel videot, mint Te...

ha baromsagokat hordasz ossze-vissza olyanrol, amihez nyilvanvaloan nem ertesz, legalabb ne nezz le mast, amiert o tobbet tud errol, hanem maradj legyszi a sarokban, csondben.

Hat, a stilusodon lenne meg mit csiszolni, ez teny, de legalabb haladunk valamerre.

Egyebkent meg elhiszem, hogy elobb streameltel elosztott rendszerrel, mint en, kerdes, hogy darabolt fajlokbol is tudtal-e streamelni. Mert tulajdonkepp ez itt a lenyeg, egy release-t nem valtoztathatsz meg (= nem csomagolhatod ki), eredeti (= becsomagolt) allapotaban viszont nem lehet streamelni. Illetve lehet, hogy meg lehet oldani, de eleg problematikus, es sok munkat igenyel.
-- 


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

a stilusom olyan amilyen. nem kell erte szeretni.

arra probaltam ravilagitani - sikertelenul -, hogy senki nem akar ilyen releasekbol streamelni. altalaban az a cuccok utja, hogy (ftp szerverek)+[0] -> torrent oldalak. en lattam mar olyan torrent oldalt (tavolrol;)), ahol kicsomagolva raktak fel a dolgokat, de ez ritkasag.

[0]: a + jel a tranzitiv lezart

Az ilyen releasekbol valoban senki nem akar streamelni, nyilvan, mert nem is tud. Azonban a nagyon jo minosegu release-k sokszor ilyen formatumban kerulnek kiadasra, amit viszont jo lenne streamelni - de nem lehet. En pedig erre a problemara probaltam ravilagitani.
-- 


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

nem a 4G miatt vannak darabolva. de amugy a 4G is probelma lehet, mert az ftp protokollban nem definialjak, sot mar 2GB folott gond van a legtobb ftp _klienssel_ (sok wines szar, de mc se jobb), amikor folytatni kell egy mexakadt letoltest.

a darabolas egyebkent eredetileg a torrent es tarsai szimulacioja miatt volt anno, csak warez sceneben racelesnek hivjak, elkezdi valaki tolteni a rar-okat es kozbe mas szerverekrol is toltik a tobbi filet. igy a cucc kulonbozo darabjai kulonbozo szerverekrol jonnek, epp ugy mint a torrentnel. ha valamelyik rar hibas (crc nem stimmel az sfv fileban) akkor azt ujratoltik mashonnan. a vegen lehet sfv alapjan ellenorizni (kb mint a hash ellenorzes torrentben).

az, hogy a p2p (torrent) es az ftp scene elegge 2 kulon mufaj ma is, es gyulolik is egymast, na meg akik a 2 kozott tradelnek, nem beszleve az eltero release szabalyokrol, az mar mas kerdes, es itt elegge offtopik.

A'rpi

Annál nincs rosszabb, mint torrenten látni az eredetileg FTP-re készült, ezért tömörített-darabolt fájlokat.
Nem beszélve arról, hogy torrenten elég elterjedt trükközés a RARos darabolás, ami XY weboldalról szedhető kóddal nyílik. Az ilyet bottal nem piszkálom meg, mindig ellenőrzöm az első r00 alapján.

( nanto | 2010. 05. 31., h – 20:36 )

egy olyan mellekkerdesem lenne, hogy az svn snapshot mission nelkul elfordul minden architekturara? (elsosorban arm-ra kerdezem)
-----------
Happy, satisfied and completely up-to-date Archlinux user since 2009 september (KDE)
"Which version do you use?" "The latest stable" (a random archlinux user)