You will care if mplayer/mpv/mplayer2 stop functioning on your system. SMPlayer is NOT playing the video. It is sending the commands to mplayer/mpv and puts a shell around the actual video application.

Try this... install SMPlayer without mplayer/mpv and see how far it gets you as a "video application".

Well, install mplayer without ffmpeg/x264 or whatever and see how far it gets you. Does it mean mplayer is just a frontend for the codecs?

SMplayer might not be playing the video but it is the application. I use it for the features/GUI/convenience, not for the backend.

In essence: mplayer, mpv and ffplay are the ruling back-ends, SMplayer & VLC are the ruling desktop front-ends (ok VLC is actually more than that). Poll closed. :D

But you can build mplayer without having ffmpeg installed on your system. It will clone the repo and include it statically in the mplayer binary. You won't start with ffmpeg installed, and you won't end with ffmpeg installed, because it is still all mplayer. And when you attempt to play a file with mplayer, no other binaries need to be called on.

This is the poll that jeremy chose. SMPlayer, because it is not an actual player, just a front end application for mplayer/mpv, is not eligible. I've tried to get it added on previous years and , once it was explained, I easily understood why it was that way. I'm sorry you're having a difficult time accepting it.

VLC includes all requirements in its binary. VLC is not a front-end, since it can be a fully enclosed player. You don't need ffmpeg, mplayer, or mpv installed to use VLC. The same can't be said of SMPlayer.

If someone were to take the mplayer code and work it directly into the SMPlayer binary (so SMPlayer doesn't call mplayer separately during playback), then it would likely be included in next year's poll. Until then, it will likely remain unmentioned (except for in the comments).

Well, you won't have the ffmpeg package installed but it will be still a part of the installation. In my eyes this is just a question of technical details of no importance to actual user, and ffmpeg is still there.

Well that's the thing. I like SMPlayer; i use it for its features, for its GUI and so on . I don't care which backend sits there, i would use SMPlayer anyway. So it's my application of choice.

This is all about GNU/Linux programs being perfectly functional standalone programs as well as being able to act as a backend for another ones.

You know you can play music directly with GStreamer. Does it mean the Audio Media Player Application of the Year poll should include just GStreamer and VLC and ffmpeg? I don't think so, people choose different applications just for the very GUI (or non-GUI, to each its own).

Well it's too much arguing about nothing, really, but i'm still convinced this needs reconsideration.

I'm not sure you understand how ffmpeg is involved with mplayer. ffmpeg is not part of the mplayer installation. mplayer only utilizes the codecs contained within libavcodec (which is what VLC does as well), which is part of the ffmpeg project. That is the reason mplayer will either build off a system-installed ffmpeg or clone the repo before you compile mplayer. It needs libavcodec, which is part of ffmpeg. It does not use any part of the video playing capability of ffmpeg except for the codecs contained in the project. Would you consider the xvid codec a video player? I doubt it, so don't count libavcodec either.

And gstreamer is only available as a backend. There is no gstreamer executable for you to run.

Fact is, SMPlayer does not play videos... it generates a hugely long and complex mplayer/mpv command that is executed separately, and then mplayer, the program that is actually playing the video, starts playing the video and SMPlayer puts a border around it. It doesn't matter if you don't care what video player is actually being used, it doesn't change the fact that SMPlayer is not the one playing the videos. Add to that, the person who created the poll, jeremy, has decided mplayer frontends aren't a part of this poll.

VLC won for the 7th straight year, and 6th straight with a majority vote. Still, Slackware ships with MPlayer. One, advantage of MPlayer is that the newest version will work on older systems, even on Slackware 13.0 which was released in 2009.

mpv came in 3rd.
good enough.
next year it will be first, if the devs continue with their good work, and we get a reasonably recent version into debian stable!

I liked the M player, SMplayer and MPV but have not been able to make vid/audio sync. no matter how i set it up the lips and sound are not even close, started with defaults.
this issue and not being able to make the mouse and key shortcuts for audio and vol control configure and stay as i set it . so VLC had to be my pick by elimination.And it just works. no troubles, on almost everything.
i use all kinds of video players without issues. i use source forge in windows and Linux and never had trouble configuring. but smplayer /MPV and/or Mplayer just give me a headache.too bad. i really liked how i could configure it...just didnt do what i set up for some reason. i used GUI and the terminal (with help pages since i am still new with Linux MInt17 Mate
i keep SMplayer and MPV and continue to work with it so maybe one day i can make it work as it 'should' or hoped it would.
john

VLC & Smplayer

It's still Mplayer, but i just wanted to give a shout out to UMplayer. I just tried it for the first time, and it is exactly what i have been looking for. I have tried Gnome-mplayer, and SMplayer and they don't know how to retain window settings which is incredibly annoying. (I'm using Mate at the moment, but i'll add that i've used KMplayer before in KDE and it was pretty nice.)

Thank you UMplayer, it has finally given me exactly what i wanted within Mate.