On Jun 10, 2014, "Raphaël Jadot" <[email protected]> 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. >The >> 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 >on >> 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.
