No tak to jsem rad, ze ma nekdo podobnou zkusenost. Nechci rict, ze uplne vzdycky, ale ve vetsine pripadu mi mplayer vyhodil nejakou chybu. Tak jsem to radsi v klidu vsechno prehral v obycejnem Totemu. Ovsem ted jsem narazil v nejakem blueray ripu, ktery mi neprehral smysluplne ani VLC. A svete div se, pomohl mplayer2. Uz je nejaky cas v debian squeeze-backports a v kombinaci s smplayerem si ho nemuzu vynachvalit. Dokonce lze u smplayeru nastavit gtk interface a v minimalisticke variante ma pro mne i prekousnutelny vzhled. Je tam jen tlacitko play a tusim stop, hlasitost a seekovani :0) Subjektivne mi prijde, ze prehrava filmy ve vysokem rozliseni i s mensimi naroky.
Nepřehrávané video je pravděpodobně způsobené špatně zvoleným výstupním driverem.
Viz volba -vo (http://www.mplayerhq.hu/DOCS/HTML/en/video.html)
Netusite nekdo proc vlastne ten fork vzniknul? Vim, ze autor mplayer2 mel urcite "neshody" s hlavnimi vyvojari mplayeru, ale v cem byl ten problem?
Prijde mi, ze vetsina tech novych funkci v mplayer2 dava z pohledu uzivatelu smysl - lepsi vykon, vypilovani ruznych vlastnosti, snadnejsi udrzba balicku v distribucich (tohle snad musi byt v zajmu kazdeho vyvojare)... to jsou opravdu core-vyvojari mplayeru tak omezeni, ze nejsou ochotni takova vylepseni projektu prijmout?
Tak, neshody, myslím, že autorovi se pracovalo samostatně lépe, některé jeho změny byly odmítnuté, a posléze už měl prakticky vlastní strom změn, u něž nebyla ani teoretická šance na sloučení.
Ta historie je mimochodem o hodně delší než rok. U6 léta (snad od roku 2008?) existovala větev Mplayeru v gitu, v které si hospodařil vývojář pozdějšího MPlayeru2 uau. Jelikož bylů do té doby kmenovým vývojářem, odmítal, aby se to označovalo jako fork s tím, že to přece má podobný nárok na legitimitu jako ten druhýs trom v SVN, do kterého přispívalo sice víc lidí, ale hlavní vývojář byl taky spíš jeden (Reimar), alespoň z toho, oc jsem viděl/slyšel.
No každopádně před rokem se stalo pouze to, že se ten fork zoficiálnil, a z "MPlayer.git" se stal "Mplayer2". Oni ho totiž kamarádi nějakou dobu před tím (asi tak před půl rokem) oficiálně vyšoupli z týmu, a tak mu už nic jiného ani nezbývalo. Ten kód ale existuje a je používán mnohem déle, jak už jsem řekl.
On ve skutecnosti existoval Mplayer 2 uz nekdy kolem roku 2004. Tehdy na nem zacal pracovat puvodni zakladatel Mplayeru Arpi, kdyz zjistil, ze se se single thread Mplayerem uz toho moc delat neda. Od ty doby co Arpi opustil Mplayer se taky vyvoj Mplayeru vicemene omezil na updatovani kodeku a pridani ze zacatku absolutne nepouzitelnyho GUI.
Jestli ma ale tenhle Mplayer 2 neco spolecnyho s puvodnim Mplayerem 2 od Arpiho, netusim. Prestal sem to tehdy sledovat a zacal pouzival mnohem uzivatelsky privetivejsi VLC.
Netusite nekdo proc vlastne ten fork vzniknul? Vim, ze autor mplayer2 mel urcite "neshody" s hlavnimi vyvojari mplayeru, ale v cem byl ten problem?
Prijde mi, ze vetsina tech novych funkci v mplayer2 dava z pohledu uzivatelu smysl - lepsi vykon, vypilovani ruznych vlastnosti, snadnejsi udrzba balicku v distribucich (tohle snad musi byt v zajmu kazdeho vyvojare)... to jsou opravdu core-vyvojari mplayeru tak omezeni, ze nejsou ochotni takova vylepseni projektu prijmout?
Mplayer! ono to ještě žije? Mplayer byl impuls který mě kdysi přivedl na linux (cca rok 2000). Dokázal přehrát i všechny díly Červeného Trpaslíka na kolejní síti aniž by se co deset minut seknul jako to dělalo pravidelně WMP.
Dodávám, že jednalo se o velmi nekvalitně encodovana videa.
Dělá na to stále Arpi? tedy původní autor mplayeru?
Tak oni nikdy nevydají ani verzi jedna, uvíznouce v nekonečné "rc" sérii, v navazující "svn-only" sérii, když došla distribucím trpělivost, a tramtadadá, máme tu preventivně verzi 2 :)
Tedy release management je u OSS někdy námět na grotesku. Nebo horror. Což je třeba případ ffmpegu. A to je o moc horší, protože nad ním staví kde co.
Otázka je, má to ještě cenu když máme VLC?
Oba stojí nad ffmpegem, takže v konečné důsledku budou umět to samé.
VLC má už teď slušné GUI, stabilní vývoj ba i smysluplné verzování.
Nebo oživit Xine, To už integrované je, asi ze všech přehrávačů nejlépe. Pokud vím, je to sále doporučovaný backend pro KDE4 Phonon. Ba možná jediný spolehlivě chodící. Bohužel tenhle projekt je nějak u ledu. Xine2 nebude?
Správně chápu, že mplayer2 bude stavět na systémové knihovně ffmpeg?
No bych taková výhra být nemusela. To že mplayer staticky linkoval ffmpeg alespoň zaručovalo, že daná kombinace bude chodit. I Xine a Vlc to tak dělají.
Leda, že by se release management ffmpegu radikálně zlepšil.
Arpi v tom nejede už léta. Taky snad odešel/(byl odejit?) pro neshody...
VLC jsem teď tak rok docela chválil, ale teď se mi zdá, že nějak rozbili chroma upsampling při použití GL výstupu (a navíc ten učinili výchozím), na windows dokonce přestali jít titulky s výstupem directx, a rychlost gui se nějak snížila... takže teď je zřejmě MPlayer/Mplayer2 s použitím gui (SMPlayer/SMplayer2) lepší volbou...
Ale jelikož koukám na WXP, tak stejně používám mpc-hc/cccp a to je ze všeho nejlepší :D
Iba tak mimochodom uz i klasicky mplayer zacina pracovat na podpore viacerych vlakien. Treba build z SVN + parameter pri kompilacii a prehravani a ono sa to snazi vytazit viac CPU.
Zbytok ako dynamicke linkovanie FFmpeg moze byt i na skodu koli kompatibilite a taktiez asi vyvojari vedia preco "vrtaju" do vnutra kniznice a nie cez API. Dufam ze tato snaha povedie ku spojeniu oboch forkov nech sa zbytocne netriesti kod... Ale kiez by tam boli iba technicke prekazky.
V klasickém Mplayeru podpora více vláken byla už dávněji - stačilo si zkompilovat ffmpeg/libav s podporou více vláken. Protože však v defaultu byla používána vanilková knihovna, tak to MPlayer oficiálně "neměl". To se změnilo, když byla podpora více vláken definitivně včleněna do ffmpegu a libavu (2011).
Jinak MPlayer má léta i to renderování přes libass, jen to není defaultně zapnuté.
Ono to totiž není pravda. Jde o to, že MPlayer"1" měl tyhle knihovny zabodované coby jakési interní forky (podobně ffmpeg, který byl ale updatován a libass). Mplayer2 pokud tomu dobře rozumím tohle ruší a tyhle knihovny se využívají normálně, tj. nainstalujete a updatujete je zvlášť (na webu se říká, že stará metoda funguje, když si ty věci manuálně nakopírujete do adresáře...).
Uz dost dlouho mplayer2 pouzivam a je o hodne lepsi jak klasicky, viz ta pauza (ktera me skutecne vytacela). A i na slabem 2 jadrovem atomu zvlada bez podpory grafiky prehrat fullHD videa diky podpore vlaken, coz vlc si v tomtpo pripade ani neskrtne.
Osobne nepouzivam zadne GUI, vse podstatne mam nastavene v konfigu a namapovane nejdulezitejsi operace na mys. Sice semtam musim sahnout i na klavesnici abych napr posunul casovani titulku, ale stejne mi GUI neschazi, ba naopak by mi prekazelo.
Pro tyhle účely má Mplayer2 speciální výstup -vo lavc. Myslím, že o ještě nebylo mergnuto a bohužel odkaz ze stránky projektu háže 404. Takže možná se poptejte u nich v kanále.
Pokud vím, existovaly patche pro starý mencoder, které umožňovaly v něm používat filtr libass. A další možnost: ffmpeg (pozor, ne libav) udělal myslím z libass video filtr, tak snad by se to dalo rozběhat tak.
To bude proto, že kdy dekódujete pomocí vdpau, zůstávají dekódovaná data v RAM grafiky a MPlayer je neumí natáhnout zpět, aby mohl vložit filter "expand" (který vám přidává ten černý pruh). Video výstup se připojuje přímo na enkodér a vykreslování titulků tak lze provést jenom do framu videa.
Jinak na titulky v černém pruhu často vývojáři kašlou, protože to dělá komplikace při čumění na anime - ass titulky často obsahují souřadnice s pozicemi, a když přidáte černý pruh, změníte tím rozlišení a AR, a ty titulky s určenou pozicí budou zobrazené špatně...
Nevím o ní. 1) Musel by se naprogramovat filter který by běžel v RAM grafiky, nebo 2) muselo by se naprogramovat načítání dekódovaného videa zpět do operační paměti (což je proveditelné), nebo 3) musel by se nějak přidat další černý obdélník pod okno videa nezávisle na výstupním modulu videa a tam nezávisle vykreslovat titulky (a hlídat si přitom časování a změny velikosti okna), což by asi byla docela otrava naprogramovat...
Pro zajemce o testovani: http://repos.fedorapeople.org/repos/jmoskovc/mplayer2/fedora-16/
- spec pro mplayer2 jsem si "pujcil" tady: http://mso-chronicles.blogspot.com/2011/03/mplayer2-experimental-package.html
- spec pro libav je jen v rychlosti upraveny spec pro ffmpeg
Za prve, myslim, ze na 99% prava maji, jelikoz je to screenshot, tedy fair use, a za druhe, pokud se nemylim, autorska prava vlastni BBC, tedy potazmo britska verejnost, a nepochybne je zase koupi i CT, takze koho tohle probuh zajima?
Vy budete asi jeden z tech typu, co se hlavne stara, jestli ho soused nema vetsiho...
Zkoušel jsem nainstalovat mplayer2 na Fedoru. Jako GUI jsem použil SMPlayer. Výsledek: obraz jede, nové fíčury fungují (např. posunutí dozadu o 10 sekund při pauznutém filmu ho skutečně nespustí, jak inzerují), ale:
NEJEDE ZVUK :(
Dal jsem zpátky mplayer, zvuk opět jede.
Prostě neotestovaný nedodělek, jak je tomu BOHUŽEL často zvykem v Open source. Je mi to líto.
treba proto - https://github.com/lachs0r/SMPlayer2 - co ja vim :)
No přesně něco takového to asi bude. Jenom bych očekával, že když napíšou "The protocol is compatible and most of the functionality differences do not cause problems for the GUIs" tak bude stačit v SMPlayeru prostě nahradit cestu k mplayer cestou k mplayer2 a bude to hrát. Zase jenom další ukázka, jak OSS produkty nejsou zralé pro koncového uživatele.
Zdravim,
umi tenhle NEJ prehravac ^2 koncne prehravat rozumne DVDcka?
At konecne muzu opustit neovladatelny VLC? Ktery ale umi narozdil od mplayeru (ci mplayeru2?) prehravat DVD filmy.
Abych upresnil... dokud to DVD nenaripuji pomoci mencoderu, tak jsem sice schopen docilit pusteni filmu, ci cehosi...ale v tak zasekavany verzi, ze se na to neda divat.
Na Win pouzivam ruzne klony mplayeru vcetne SMplayeru na linuxe radeji cisty mplayer, ikdyz sem tam i smplayer.
Diky za rady a tipy.
Zkusil jsem nainstalovat z repozitářů na Kubuntu 11.10. Starý mplayer se tím odinstaloval a mplayer2 se spouští příkazem mplayer (bez dvojky). Bohužel mi ale nefungoval. Video se dobře spustilo, ale při zapauzování nebo pokusech o posun vždy zatuhnul. Na konzolu to psalo něco o bindování kláves, bohužel se přesně nepamatuju. Dal jsem zpět starý dobrý mplayer, se kterým nemám problémy.
nic proti autorovi ale oznacit mplayer/mplayer2 za najlepsi prehravac mi pride trochu uletene.
ano, mozno dokaze par veci ktore ine prehravace nie. Ale niektore ine podstatne features uplne chybaju alebo su na urovni praveku a tymto sa dostava tento prehravac skor nepouzitelnym
1. GUI (supluje SMplayer nebo SMPlayer2). On toitž při seekování nebo navigaci v kapitolách je takový progressbar docela dobrá věc.
2. Při použití ass titulků vám MPlayer(2) na windows analyzuje adresář s fonty pokaždé, když nějaký nainstalujete (docela opruz) a může za to fontconfig.
3. Screenshoty mají mizernou kvalitu chroma upsamplingu (dtto -vo png). V bugzille je však patch, takže tohle se možná po letech změní
4. Původní Mplayer na konci přehrávání ošklivě zadrhával se zvukem (pokud tam nebylo ticho). Nevím, jeslti tím trpěli všechny výstupní moduly a nevím, jestli toto náhodou MPlayer2 neopravil.
5. Na windows nezvládá otevřít soubor, když jsou v cestě znaky mimo nastavené locale... SMPlayer tohle obchází přes 8.3 názvy (...)
Vzhledem k tomu, že si v něm video nepouštím (pokud nepotřebuju juknout na h.264 ES), tak jsem na něco určitě zapomněl.
Ale jinak je to dobré. Na windows bych si ho nevybral, protože GUI Smplayer přece jen nemá až tak rychlou odezvu (komunikace s backendem) a MPC-HC v kombinaci s ffdshow má pro mě další výhody.