IIRC mplayer development is somehwat dead because of lot of forks i.e mplayer2.
Well we should do some research on mpv2 whether it is worth to do the switch in some future. 2014-06-10 14:07 GMT+02:00 Raphaël Jadot <r...@hodo.fr>: > > > > 2014-06-10 13:04 GMT+02:00 Symbianflo <symbian...@mandrivausers.ro>: > > On Jun 10, 2014, "Raphaël Jadot" <r...@hodo.fr> wrote: >> >>> >>> >>> Hello, >>> >>> today I read a news in linuxfr, as it may interest you (also thinking >>> that it may interest symbianflo both for OMLx and ROSA Linux), I made a >>> quick translation. >>> >>> http://linuxfr.org/users/pseudo007/journaux/mplayer-est-presque-mort-vive-mpv-et-vaapi >>> >>> >>> Title (which may seems a troll :p): Mplayer is (almost) dead, long live >>> Mpv (and VAAPI) >>> >>> Less than a year ago I bought a new PC from scratch, keeping nothing >>>> from the old. >>>> I took something "modern" without exageration. >>>> [...] >>>> I was for many years a happy user of Mplayer. With the rising of High >>>> Definition, I was less. The problem of synchronization of the video (a >>>> little "chopped") arose more even with a recent CPU. The problem is >>>> also associated with Mplayer. Intel graphics cards (found on the i7 >>>> CPU and others) allow decoding and displaying the video via VAAPI >>>> interface. There is VAAPI for Mplayer, separated here: >>>> >>>> https://gitorious.org/vaapi/mplayer/source/e4a658ef28e09e8441630f9028506f5cf7449480 >>>> : >>>> >>> I used it, the CPU consumption drops drastically through VAAPI, but ... >>>> There were still problems of synchronization (eg Freeview HD, which in >>>> addition has almost always an audio/video offset). >>>> This branch of Mplayer is not updated since a long time and each time >>>> there was a new version of Mplayer, I had to redo the patch. It is not >>>> fun in the long run. Finally I gave up. >>>> >>>> One day I discovered that Youtube offers 2160h videos (against 1080 >>>> height for the current HD). Example taken randomly >>>> https://www.youtube.com/watch?v=suWsd372pQE >>>> Useless to rely on Flash to see this in 2k. We can recover the video >>>> with youtube-dl (size 138). I used mplayer and I got: >>>> dimensions are too high: 3840x2160 (maximum is 2048x2048) >>>> You can get around with "-vf scale=..." but it puts the CPU to its >>>> knees, or use "-vo gl". In any case the result stays chopped. And >>>> voila, all my gleaming new hardware is already obsolete. >>>> Of course, there is the problem of displaying such video physically >>>> (2160h screen and link with the screen), but let's put it aside. Youtube >>>> videos being not very well coded, 2016h videos encoded by Youtube gives >>>> good 1080h. >>>> >>>> I have modern equipment, but I can not read properly recent videos >>>> formats. >>>> Would it be not possible with the latest equipment to read properly >>>> recent video formats on GNU/Linux? >>>> It would hurt me. >>>> >>>> Then I stumbled Mpv: http://mpv.io/ >>>> In outline, this is a fork of Mplayer/Mplayer2 who wants to go ahead >>>> and get rid of all the historic Mplayer balls and chains. Mpv is >>>> compatible with Mplayer and is the legacy of the fork, but it is not a >>>> priority fpr them, and there are incompatibilities. Mpv integrates >>>> VAAPI. >>>> I have a Fedora 20 [...], mpv is in the rpmfusion repository. So "Yum >>>> install mpv". Rpmfusion got the 0.3.6 release. I updated to 0.3.10 a >>>> few hours ago just to see, it does not change much, just less bugs. >>>> >>>> To use vaapi with Mpv: mpv -vo vaapi (or opengl) --hwdec=vaapi >>>> You can also tinker /etc/mpv/... or ~/.Mpv/ to shorten the command line. >>>> Mpv with vaapi and the cpu consumption is falling, NO synchronization >>>> problem (finally!). For 2160h video Youtube 2160h, I can run it 2 >>>> times in parallel with "-speed 2" (60 fps), easy, fluid. Less than 10% >>>> CPU with Mpv (for a thread, the CPU has 8 threads). Very greedy >>>> Blu-ray are (finally) flawless. >>>> >>>> NB: remember to have the frequency of the screen that corresponds to >>>> the video, or a multiple, for it to be really fluid. Therefore check >>>> Modeline and "xrandr --newmode" "xrandr --addmode" "xrandr --rate". >>>> >>>> I do not do here a complete test of Mpv, I use it only for 2 days. T >>>> he project is new but impressive... >>>> >>>> Farewell Mplayer, thanks for services rendered, and welcome to Mpv. >>>> I only found one regression from Mplayer. With VAAPI on Mplayer, we >>>> can ask the graphics card to "deinterlace" interlaced video. With >>>> Mplayer there was a doubling of the fps (like "-vf tfields" ). With >>>> Mpv, although the doc says it's "bob" deinterlacing , this is not what >>>> I saw. >>>> Another advantage of VAAPI, we do not have the problem of the screen >>>> which is refreshed with the image of the video that is actually composed of >>>> 2 images, because the reader write in the memory of the graphics card at >>>> the same time drive. >>>> There is a trick to gnome-shell if you do not use VAAPI which avoids >>>> this problem but is not enabled by default. >>>> >>>> Not only VAAPI can decode and display videos, VAAPI also can encode. There >>>> are very basic tools in the package libva-utils, they are damn fast (more >>>> than 25 fps in 1920x1080 loseless) and it consumes nothing. The CPU >>>> that integrates the graphics card does not heat. It is stunning. I >>>> hope one day coding via VAAPI will be supported by ffmpeg (or mpv that can >>>> encode like mencoder). >>>> >>>> Mpv is a best video player than Mplayer, but it also has some >>>> significant refinements. For example, if you stop the video reading >>>> with a 'Q' (instead of 'q'), Mpv backup the configuration including reading >>>> position. When one reads again the file, the video starts from last >>>> position. By pressing '.' with Mplayer we can do frame by frame >>>> reading. Ditto for Mpv, but pressing ',' we can do it backwards. With >>>> Mplayer >>>> if you wanted a screenshot, you had to restart with "-vf screenshot". Mpv >>>> inserts o n the fly the plugin if you press 's'. This is just an >>>> appetizer, the rest is to be discovered here: http://mpv.io/ >>>> >>> >> >> Thx for considering me in.. :-) I've ported mpv in rosa, ( see resa >> bugzilla/ package request), also I had a discussion with Pulfer about >> this, it might be that mplayer have a very slow development, but mpv is >> not ready to replace anything, beside, vaapi is a very ugly feature for a >> even uglier hardware, AFIC ati was,is, and will be a linux user >> nightmare... while vdpau&&cuda are really awesome, design for a even >> awesome hw.... >> Now if you consider this mail as a pkg req. Ok it can be done, I always >> can backport my build from fresh, but IMO , that's it, also because in oma >> ,we already have a bad choice in multimedia stack, see vlc..., for another >> one I'm not prepared, and I wont fix it not even in mrb.... >> So if the majority goes for mpv then be it but , count me out. >> An also I would gladly here Bondrov's take on it, since he's the mmedia >> stack master in main (on rosa, of course,). >> So think twice, let's don't end up bad as we did with vlc.... >> Greetings. >> -- Sent from my Asus transformer pad with K-@ Mail. Please excuse my >> brevity. >> >> >> >> > Hi Symbianflo, > > it's not a pkg request, I have absolutely no knowledge about multimedia > stack, and almost no needs:) > > It was just for information, in case it may help someone > > > > > >
