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/ >
