Jeśli zastanawiacie się, czy w temat wkradł się błąd - uspokajam... błędu nie ma. Mało kto wie, że istnieje fork popularnego odtwarzacza multimedialnego MPlayer o bardzo podobnej nazwie MPlayer2. Pierwsze wydanie kandydujące do wersji stabilnej ukazało się 1 marca 2011 roku, natomiast w chwili obecnej dostępna jest wersja oznaczona jako Release Candidate 2. Projekt jest na tyle ciekawy, że zastąpił oryginał, który towarzyszył mi od kilku lat.
Drobne różnice względem MPlayera 1.0
Bardzo fajną modyfikacją jest zmiana zasady działania zatrzymania obrazu. W pierwowzorze, kiedy mieliśmy zatrzymany film, wykonanie dowolnej operacji powodowało wznowienie odtwarzacza. W końcu zostało to zmienione i na "pauzie" możemy dopasować dowolne parametry obrazu bez tej uporczywej cechy.
MPlayer2 posiada bardziej dopracowaną obsługę formatu Matrorska oraz zarządzanie rozdziałami. Sporym modyfikacjom poddano także działanie VDPAU na kartach graficznych NVIDIA. Przede wszystkim zniesiono ograniczenie częstotliwości przełączania klatek filmu, które dotychas były ograniczone częstotliwością odświeżania monitora (typowo 60Hz) - pozwala to odtwarzać filmy zapisane z szybszym frameratem (tak, są takie) lub przewijać materiał do przodu bez efektu przerywania odtwarzania.
Miłym udogodnieniem jest również bardziej precyzyjne przeszukiwanie materiału wideo. MPlayer 1.0 pozwalał bowiem na przewijanie jedynie do najbliższych klatek kluczowych - ograniczenie to również zostało zniesione.
MPlayer2 to również szereg innych zmian, takich jak: poprawa synchronizacji dźwięku z obrazem, wyczyszczenie komunikatów termianala, pozostawanie w trybie pełnoekranowym w momencie automatycznej zmiany odtwarzanego pliku, obsługa kontrolki głośności OSS4 oraz odtwarzanie ścieżek audio bez słyszalnej przerwy pomiędzy dwoma utworami (opcja -gapless-audio). Ciekawostką jest również danie możliwości zmiany ustawień korekcji kolorów w standardzie ITU-R BT.601 dla CVBS (SD) oraz ITU-R BT.709 dla materiału HDTV (HD).
Jest jeszcze jedna istotna sprawa, której poprzednik może jedynie pozazdrościć ...
FFmpeg-mt - wielowątkowość pełną gembą
Temat biblioteki FFmpeg-mt ma swój początek już w 2008 roku, kiedy ogłoszono osobną gałąź podczas projektu Google Summer of Code. Miała ona na celu wprowadzenie obsługi dekodowania strumieni z wykorzystaniem wielowątkowości (multi-threaded decoding). W praktyce pozwala to na znaczne przyspieszenie na procesorach wielordzeniowych. Jak się okazuje - również na procesorach dwurdzeniowych. Warto wspomnieć, że trzy dni temu, FFmepg-mt został dołączony do głównej gałęźi rozwojowej i powinien zadebiudować w wydaniu FFmpeg 0.7.0.
Aby pokazać jakie korzyści przynosi owe rozwiązanie, przygotowałem małe porównanie. Testom poddałem MPlayera 1.0 rc4 oraz młodszego brata 2.0 rc2. Na materiał dowodowy wybrałem animację Sintel w trzech różnych rozdzielczościach : 1024x436, 1280x544 oraz 2048x872. Platformą testową została moja stara Toshiba z procesorem Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz i kartą graficzną ATI Mobility Radeon HD 3400 pracującą pod kontrolą otwartoźródłowych sterowników.
Już na samym wstępie odtwarzacz poinformował o próbie dwuwątkowgo dekodowania obrazu.
- ==========================================================================
- Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
- Asking decoder to use 2 threads if supported.
- Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
- ==========================================================================
Materiał H264: 1024x436, 24 bpp, 24 fps, 718 kbps
Zobaczmy jak rozkłada się obciążenie na dwa rdzenie, przy odtwarzaniu materiału o niższej rozdzielczości. Możemy zauważyć, że MPlayer2 rozkłada zadanie bardziej równomiernie - różnice jednak nie są w ogóle odczuwalne w obu przypadkach.
MPlayer 1.0 rc4

MPlayer2 2.0 rc2

Materiał H264: 1280x544, 24 bpp, 24 fps, 1616 kbps
Sytuacja ulega zmianie przy większej rozdzielczości. W przypadku starszej wersji, obciążenie w większym stopniu nie jest rozkładane równomiernie pomiędzy dwa dostępne rdzenie, osiągając maksymalny pułap 60%. MPlayer2 prawie idealnie rozłożył zadanie na poziomie 40% na rdzeń. Pomiary, pomiarami - jednak film w obu przypadkach odtwarza się również bez zajęknięcia.
MPlayer 1.0 rc4

MPlayer2 2.0 rc2

Materiał H264: 2048x872, 24 bpp, 24 fps 2353 kbps
Dopiero przy wysokiej rozdzielczości nowy MPlayer2 pokazuje pazurki. MPlayer 1.0 nie poardził sobie ani z równomiernym rozkładem, ani z płynnością odtwarzania. Film gubił klatki, a dźwięk nie był zsynchronizowany z obrazem, natomiast obciążenie obu rdzeni skakało jak szalone do 100%. MPlayer2 zaprezentował śliczny, równomierny rozkład na poziomie 80%, pozwalając cieszyć się pełną płynnością odtwarzania.
MPlayer 1.0 rc4

MPlayer2 2.0 rc2

Czego MPlayer2 nie ma?
Na chwilę obecną MPlayer2 nie posiada MEncodera, który pojawi się w późniejszej wersji. Rozważana jest nawet możliwość implementacji jego funkcji bezpośrednio do odtwarzacza. Dla wielbicieli GUI wielką wadą może okazać się brak interfejsu graficznego (gmplayer). Planowane jest jednak stworzenie implementacji zewnętrznego interfejsu graficznego. Jak wiadomo, MPlayer posiada wewnętrzną powłokę GUI.
Zainteresowanych i niebojących się zmian zapraszam na oficjalną stronę projektu, mieszczącą się pod adresem http://www.mplayer2.org/









Komentarze (12)
morsik / 25 mar 2011 / 00:04 Strona www «
Świetny wpis. Rzeczywiście nie wiedziałem, że istnieje coś takiego jak mplayer2. Już się zabieram za instalowanie i testowanie (-;
Domker_ / 25 mar 2011 / 10:24 Strona www «
^^ Ciekawe. Używałem jakiś czas temu mplayer (1), ale porzuciłem go na rzecz VLC do którego przyzwyczaiłem się pod Win. Bardzo jestem ciekawy jakby porównać VLC VS. mplayer2. Niestety sam przetestować nie mogę, bo mam jeszcze starszy sprzęt Korneliuszu niż Ty :}
Ave! / 25 mar 2011 / 15:43
"pełną gembą"
:d
Sam program ciekawy, aczkolwiek nigdy nie mogłem się przekonać do MPlayera. Ciężko powiedzieć czemu, po prostu bardziej mi po drodze z VLC i Kaffeine :)
vnu007dl / 25 mar 2011 / 17:26
Jak to skompilować?
W instrukcji jest:
$ ./init --shallow
$ make -j 6
$ make install
Ale mi coś takiego w tych źródłach nie wchodzi:
darek@kubuntu-pc:/tmp/mplayer2$ ./init --shallow
bash: ./init: Nie ma takiego pliku ani katalogu
darek@kubuntu-pc:/tmp/mplayer2$ ./enable-mt
bash: ./enable-mt: Nie ma takiego pliku ani katalogu
darek@kubuntu-pc:/tmp/mplayer2$
Za to sama komenda make -j 6, tylko jak dodać opcje enable-mt?
Korneliusz / 25 mar 2011 / 17:38 Strona www «
wystarczy samo make, skompiluje się z obsługą mt
vnu007dl / 25 mar 2011 / 18:34
No pięknie działa, wreszcie filmy w jakości Full HD mi się nie tną. Zużycie procesora faktycznie potwierdza to samo co pokazałeś w teście. Hmm można jakoś zmodyfikować polecenie make, tak żeby się to zainstalowało w jakieś inne miejsce? Bo teraz przy instalacji są jakieś konflikty z normalnym mplayerem.
Korneliusz / 25 mar 2011 / 18:45 Strona www «
w pliku Makefile można ustawić ścieżkę, możesz zmienić też nazwę na mplayer2 i będziesz miał oba. Kolidować nie powinno, mplayer2 to w sumie jedna binarka all-in-one
marcinsud / 25 mar 2011 / 22:35
W debianie jest mplayer(1) z wielowątkowością, ale w osobnym pakiecie mplayer-mt (dokładniej w repo multimedia dla debiana). Chociaż po dokładniejszych oględzinach to chyba mplayer2 jest. Wersja pakietu 1~rc4, ale w logu MPlayer2 UNKNOWN (C) 2000-2011 MPlayer Team
Theq / 28 mar 2011 / 11:51
Jakieś słabe te bitraty, 1500kbps to może mieć dzwięk, natomiast obraz filmu w h264 to conajmniej 10 razy więcej.
gedgon / 28 mar 2011 / 20:46
"Możemy zauważyć, że MPlayer2 rozkłada zadanie bardziej równomiernie[..]"
"Bardziej rownomiernie" to nieodpowiednie okreslenie, bo "oryginalny" mplayer (pomijajac buildy mt) w ogole sie nie skaluje. Tak powinien wygladac wykres uzycia CPU: » link «
U Ciebie, prawdopodobnie inne procesy (X, menadzer okien, monitor systemu) zajmuja drugi rdzen.
PS. Z wydajnoscia Twojego systemu tez cos jest nie tak. Jak widac na zalaczonym obrazu, podobny proc (C2D E4500@2.2 GHz) nie ma najmniejszych problemow z w/w filmem w wysokich rozdzielczosciach, nawet gdy uzywany jest tylko jeden rdzen. W przyszlosci zainwestuj w lapka z Nvidia ;)
PS2. Kilka lat za pozno z tym mt (ostatni wykres mojego screena), ale jak to mowia, lepiej pozno ...
Korneliusz / 28 mar 2011 / 21:04 Strona www «
Słuszna uwaga - oryginalny mplayer się nie skaluje. Co do rozkładu obciążenia, autentycznie obciążenie przechodziło z jednego rdzenia na drugi.
Przy wyłączonym mplayerze oba rdzenie miały w granicy 5%. Zastanawiam się, czy to nie "zasługa magicznej łaty" autogroupa, którego mam w jajku ?
gedgon / 28 mar 2011 / 21:17
Hopy, to cos naturalnego, a wrecz pozadanego, nie ma to nic wspolnego z autogrupem. Na moim screenie tez sa: pierwszy wykres, watek wlasnie przeskoczyl na drugi rdzen. Na drugim wykresie zrobilem screena, gdy mplayer spedzil podobna ilosc czasu na kazdym z rdzeni (interwal 0.5 sek).