2014-06-10 13:04 GMT+02:00 Symbianflo <[email protected]>: > 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. 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
