Slashdot stories can be listened to in audio form via an RSS feed, as read by our own robotic overlord.

 



Forgot your password?
typodupeerror
Media Desktops (Apple) OS X Apple

Lack of Manpower May Kill VLC For Mac 398

Posted by timothy
from the vlc-generally-rocks dept.
plasmacutter writes "The Video Lan dev team has recently come forward with a notice that the number of active developers for the project's MacOS X releases has dropped to zero, prompting a halt in the release schedule. There is now a disturbing possibility that support for Mac will be dropped as of 1.1.0. As the most versatile and user-friendly solution for bridging the video compatibility gap between OS X and windows, this will be a terrible loss for the Mac community. There is still hope, however, if the right volunteers come forward."
This discussion has been archived. No new comments can be posted.

Lack of Manpower May Kill VLC For Mac

Comments Filter:
  • by Hatta (162192) on Wednesday December 16, 2009 @05:13PM (#30465076) Journal

    That's a good option for playing videos. But what makes VLC VLC, and not just VC, is the LAN support. VLC can pretty easily be set up as a video server as well as a player. You can't do this [engadget.com] with Mplayer.

  • Re:user-friendly? (Score:3, Interesting)

    by ickleberry (864871) <web@pineapple.vg> on Wednesday December 16, 2009 @05:26PM (#30465344) Homepage
    Strange. on Linux it opens up a new instance every time. Of course the correct behaviour would be just to have an 'enqueue' option in the context menu for that file which you can then set as the default option if you desire
  • by plasmacutter (901737) on Wednesday December 16, 2009 @05:31PM (#30465446)

    Sad to see VLC struggling, but there's always Mplayer OSX Extended [mplayerosx.sttz.ch] for the mac. Get the extra codec pack and it can play anything!

    Compare 1080p H.264 matroska playback in vlc to mplayer:

    on my macbook pro (exactly a year old at this point) vlc plays it without a stutter, mplayer extended will drop frames like an epileptic. Im sure they both drop frames, but VLC does so much more gracefully, resulting in no noticeable distortion, while mplayer extended makes it obvious (and incredibly annoying) to the viewer. Nothing like watching blade runner final cut and being slowly infuriated by those epic scenes being subjected to massive chop and screen tears.

  • by rbrito (37104) <rbritoNO@SPAMime.usp.br> on Wednesday December 16, 2009 @05:37PM (#30465604) Homepage Journal

    (This message may be seen as inflammatory, but I assure you that it is just my opinion and not particularly anybody else---I don't speak for the projects on which I participate).

    Hi.

    I am not a developer of VLC, but I am part of the LAME team (that MP3 encoder that a good amount of people use). I see similar problems regarding LAME as those described by the VLC team: lack of continuous power and resources.

    Some users just magically think that "oh, this program won't exist anymore, so let's use this other one". The sad thing here is that they are shortsighted in the fact that they, by doing nothing (just receiving the programs), are not giving the incentive for the projects.

    What about if the proposed alternative dies a few days from now? The amount of alternatives is finite.

    Not only that, but the major players out there all share the same codebase: there are "incestuous" (in a good sene of the word) relations with VLC, xine, and mplayer: the all use, to some extent or another (well, in some cases, to the full extent) some common libraries: ffmpeg, libmp3lame, theora, vorbis, dirac, x264 and so on.

    Usually, also, the players also send some feedback to the people writing the libraries and, without them, the libraries would not be as good as they are. And the feedback that developers provide is, not infrequently, in form of patches, or constructive suggestions. Some users, like the one above, just cares less and, honestly, where would you just "grab the extra codec" if they all, come, essentially, from the first place?

    If you didn't know, perhaps it is a good reminder to put here that people from the VLC project developed the nice libdvdcss library, which benefited xine and mplayer, while people in the other projects have directly or indirectly benefited the others.

    I would not like to have the "Linux desktop" mainstream with a "community" with a person that doesn't want a community. For people that are more altruistic (and that show it, instead of just playing in slashdot all day), I am open to a more open talk.

    [Gee, from what I wrote the above, it seems like if I only saw Linux---I actually value the other Unix-like operating systems as much].

    I guess that what I meant to say here is: "Talk is cheap. Show me the code. Don't wish the death of what you may proudly use and not even know".

    Regards, Rogério Brito.

  • by nxtw (866177) on Wednesday December 16, 2009 @05:43PM (#30465696)

    Compare 1080p H.264 matroska playback in vlc to mplayer:

    on my macbook pro (exactly a year old at this point) vlc plays it without a stutter, mplayer extended will drop frames like an epileptic. Im sure they both drop frames, but VLC does so much more gracefully, resulting in no noticeable distortion, while mplayer extended makes it obvious (and incredibly annoying) to the viewer. Nothing like watching blade runner final cut and being slowly infuriated by those epic scenes being subjected to massive chop and screen tears.

    The best results I've seen for a sufficiently high bitrate H.264 1080p stream on OS X was by using Media Player Classic Home Cinema running in Windows inside VMware. ~20 fps with tearing and OK audio. Compare to VLC, which was able to play the video at ~24 fps during low motion screens and then just stop updating the picture for a while if decoding couldn't keep up. MPlayer would stop playing altogether if the CPU couldn't keep up. QuickTime + Perian took forever to load the video and then froze when I tried to play it.

    In Windows with H.264 hardware decoding disabled the video plays fine. The video also plays fine in Windows (and with lower CPU usage) with hardware decoding enabled, of course. OS X doesn't support hardware H.264 decoding at all on this GPU (Radeon HD 2600). Even if it did, I don't know of any way to use OS X's H.264 hardware decoding support except on files natively supported by QuickTime X.

  • by ivoras (455934) <ivoras@f[ ]hr ['er.' in gap]> on Wednesday December 16, 2009 @06:02PM (#30466028) Homepage

    Are you really joking? VLC is the most successful open source project on Mac, forever. It even beats Firefox.

    Here is a top sw downloads listing from absolutely general user focused download site: http://www.macupdate.com/popular/ [macupdate.com]

    VLC has also become de-facto remote controlled Apple OS X software for iPhone/iPod users. Those are the true "walled garden" lovers/ignorers.

    VLC should look at their community, IRC channel, developer public comments for why on earth their developer level dropped to zero with such amazing success.

    Because "true Apple lovers" are mostly either multimedia designers, artists, writers or just ordinary users with more money than sense, and not down-in-the-trenches C/C++ developers? It will really be interesting to see how this story with VLC develops. I bet VLC would be even more successful on Mac if they charged $39.99 for it.

    Actually, I think this would be a good point to make with the developers: create a "VLC Gold" edition for Mac, which will be basically the same with some fancy Apple-like UI tweak or just a logo change, and charge for it. This way development gets funded and people get the warm fuzzy feeling of actually buying something good.

  • by msevior (145103) on Wednesday December 16, 2009 @06:05PM (#30466072)

    There are very few Open Source developers for OSX. Unfortunately we, AbiWord, have exactly the same issue. We *almost* had version 2.8 ready for OSX but we lost our lead OSX developer and there is no one to replace him. Rather than delay 2.8, we simply went ahead with 2.8 for Linux and Windows.

  • by AbRASiON (589899) * on Wednesday December 16, 2009 @08:21PM (#30467578) Journal

    I still don't see enough buffering code and SPECIFICALLY buffering controls for users in any media player.
    I frequently play back files which just happen to be close to the bitrate of my wireless connection, why can't I have the program specifically pre-buffer 100mb of data and then play back from the 100mb? Then when the bitrate is higher, it drops to 80 or 50 but when it's lower, it re-fills.
    This is pretty straightforward stuff and yet, do we have these kind of controls?
    I want this on my PS3 media playbakc, my Xbox 360, Media player classic, GOM, VLC - everything damnit! I'm willing to goddamn wait as long as the end result is a smoother experience!
    I live in Australia, youtube and many flash videos here are frankly, bloody annoying, often we open a youtube video here, click play, let it start playing then quickly hit pause so it fills the full buffer :/ (if you don't quickly hit pause and it plays up to where the buffer end is, that can be a problem too)

    FWIW: I'm not a coder, perhaps this is significantly more complex than it sounds to impliment but damnit it could make many things smoother and simpler.

  • by Anonymous Coward on Wednesday December 16, 2009 @09:27PM (#30468178)

    Yeah seems like all the good developers are very very commercial. Strange ecosystem on OS X

Old programmers never die, they just branch to a new address.

Working...