Announcement

Collapse
No announcement yet.

VLC Media Player Reaches Version 1.0

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    Originally posted by yesterday View Post
    Xine isn't cross-platform AFAIK
    He didn't mention crossplatform.

    MPC requires DirectShow codecs
    OK I'll give you that one. Been using it in Win7 for so long without any codec packs or ffdshow for my media forgot it was even a requirement for older windows

    The cross-platform MPlayer experience is a bit more complicated than VLC.
    Not really. Install exe and your done. Mplayer also gives you advance filtering that VLC doesn't and isn't as heavy on the cpu usage.

    VLC provides a pretty seamless cross-platform experience and is by default built-in with everything needed for playback.
    Except for any type of true hd acceleration, and offers just basic filtering.

    The disadvantage of VLC is that because it's one big blob whenever there is a codec update and the media that you are trying to play with it was encoded with the newer codec you have to wait for the player to be updated if it runs into trouble and you may miss out on some advance features of it as well (such as DivX 6 videos with menus and such)

    Comment


    • #12
      I would not see so many differeces in cpu usage between vlc and mplayer (and even xinelib) as all are based on ffmpeg. When you compile mplayer/xinelib with external ffmpeg then lots of code is the same. Differences are often different demuxers, gui and special features. Some tasks just can be done better with one of em. I. e. the vlc mozilla plugin seems to be more advanced compared to the mplayer wrapper, which has it advantaged too, like easy downloading of embedded videos.

      Comment


      • #13
        Originally posted by deanjo View Post
        Huh? Mplayer and xine can both be compiled the same way to use internal solutions instead of depending on external libs.

        There is also MPC on windows.
        I think you interpreted my statement backwards. When most people think of xine or mplayer, they think of them as "backends". When asked about their favorite media player people usually mention SMPlayer, Totem, Kaffiene, etc.. I wasn't saying that xine and mplayer depended on external libs - I was referring to the players that depend on said media engines.

        Not that that's a problem - SMPlayer is my personal favorite.

        Comment


        • #14
          Originally posted by Kano View Post
          I would not see so many differeces in cpu usage between vlc and mplayer (and even xinelib) as all are based on ffmpeg. When you compile mplayer/xinelib with external ffmpeg then lots of code is the same. Differences are often different demuxers, gui and special features. Some tasks just can be done better with one of em. I. e. the vlc mozilla plugin seems to be more advanced compared to the mplayer wrapper, which has it advantaged too, like easy downloading of embedded videos.
          I've got a quite a few HD rips (720p) Kano that will play fine in other players on a fine also based on ffmpeg but on vlc on the same system it will drop frames and have a hard time staying in sync ( old AMD64 Socket 754 3200+ windsor core ). As it happens in both windows and 3 different linux distros in VLC vs smplayer the issue is indeed with VLC itself.
          (yes video and audio outputs are configured the same on both players and post proc and filter free options identical)

          Comment


          • #15
            Originally posted by Joe Sixpack View Post
            I think you interpreted my statement backwards. When most people think of xine or mplayer, they think of them as "backends". When asked about their favorite media player people usually mention SMPlayer, Totem, Kaffiene, etc.. I wasn't saying that xine and mplayer depended on external libs - I was referring to the players that depend on said media engines.

            Not that that's a problem - SMPlayer is my personal favorite.
            Mplayer has been a player first and for most since it's creation. Your common backends are xine and gstreamer.

            Comment


            • #16
              Don't you think that could be a demuxer problem? Best give em some test files which are problematic. The demuxers are really different between those players and that can lead to choppy playback when frames are skipped.

              Comment


              • #17
                Originally posted by Kano View Post
                Don't you think that could be a demuxer problem? Best give em some test files which are problematic. The demuxers are really different between those players and that can lead to choppy playback when frames are skipped.
                Could be. I never really investigated it much further after players with vdpau came out.

                Comment


                • #18
                  For xinelib + vdpau i had some bad files too which are now working.

                  Comment


                  • #19
                    Originally posted by Kano View Post
                    For xinelib + vdpau i had some bad files too which are now working.
                    Sure I can see that happening. Files being able to play in one player vs the next. By far the most robust solution I have found implementing vdpau is xbmc. IIRC vdpau is still not part of the official release of xinelib and still under development. That being said, I have already found a couple of files of mine that will not play in VLC but will in XBMC.

                    Comment


                    • #20
                      Originally posted by deanjo View Post
                      Mplayer has been a player first and for most since it's creation. Your common backends are xine and gstreamer.
                      Nevermind.

                      Comment

                      Working...
                      X