In very sad news they've removed the Shoutcast integration inside of VLC. This was one of the great 'hidden' features of VLC-you could view essentially any type of video or audio through a very slick integrated menu.
Darn AOL for strong arming them into removing the feature.
VLC was my preferred player in Windows, and still remains my default in OS X. There is nary a format which the orange pylon cannot handle. Thanks to the VLC and FFMPEG guys for all the hard work!
Last I checked something with their .flv support was bad. It might have been the splitter or something. With a lot of .flv's you couldn't seek to anywhere in the file.
As of 1.0.5 there were still some codecs missing, causing the annoying error message which ends in "There is nothing you can do about this" or something similar. It's not clear to me that this is something that can be fixed with code, though, sadly.
You could write to a text file, in broken English, a vague description of a song and I bet VLC could still play it. Great piece of software, thanks to the devs.
I'm seriously impressed with how far VLC has come in the span of a few years. Crud files go in, perfection comes out. I wish more software was this robust.
The Mac OS X version is 64 bit, which means it'll work with 64-bit HandBrake. Previously you had to use an odd prerelease build. This is what I was waiting for!
No disrespect to VLC but I just did a side by side comparison with MPC HC and VLC player and the MPC HC player looked much more clear - http://i.imgur.com/Mc2oS.jpg. Any reason behind this?
I use both VLC and MPC-HC on my machines. On the lower end computers I've noticed a large performance difference between the two: MPC-HC can crank out 720P on my 5year old laptops without hiccup, but VLC stutters all over the place.
I've heard some recommendations on how to configure VLC to be more responsive, but the fact remains MPC-HC performs better "out-of-the-box" than VLC.
I still keep VLC around for anything MPC-HC has trouble playing, however, as VLC truly does play just about anything if it is playable at all.
> so far, on Windows, VideoLAN is quite sad to be forced to recommend nVidia® GPU, until ATI® fixes their drivers on Windows
I noticed that MPC-HC uses much less CPU (using the GPU I assume. Are there any tweaks to get VLC to do the same? Or is this quote above an indication that this just doesn't work well in ATI cards?
BTW, I'm using ATI hardware and I find CPU usage around 10-20% in MPC-HC vs ~50% in VLC. In spite all VLC's other awesome features, The CPU useage and resultant fan noise are a bummer.
You really should use Sparkle for the OS X release. VLC is one of the few apps that doesn't use it and the built in updating mechanism in VLC never works anyway.
I don't see added support for the Broadcom HD decoder that Asus is shipping in some of their newer model Eee PCs (1005PR). Anyone know if there plans to add this? It would really help out HD decoding on the low-end platforms (esp since the cards aren't integrated, so they can be bought as add-ons as long as your low-end machine has a slot).
Couldn't an adapter/driver for VAAPI be written? Their kernel module is open-source and now community (I think it's currently a 'community of one') maintained.
Well, those are pretty simple.
For many reasons (that are debatable, but maybe this isn't the right place?), VLC can decode on the GPU and then gets the data back from the GPU to filter/restream/reencode to finally display it. Even if this isn't the fastest way, there are good reasons for it (I can explain if needed...)
On ATI drivers, the data back path is slow, and you need a special GUID that ATI doesn't want/cannot to communicate.
Adobe uses it, we cannot yet.
I believe this will be fixed in the future.
I'd personally be very interested in hearing some details about this, if you have a few moments to write something up (or even paste a few links to some mailing list posts or the like, somewhere that I can do some reading).
First, remember that VLC is not a media player. It is a framework, like GStreamer, QT or DS. It works in the same way, with modules/plug-ins/objects that are loaded when needed.
For the matter of GPU/DSP decoding, you have two choices: either you do a codec module abstracted and independent from the rest of the modules or you plug a special codec module to a special renderer module (and violates your clean separation, but well...)
The second is faster, of course. But...
But, then you cannot control anything: depending on the GPU/DSP vendor, you will have different filters (deinterlacing, noise, gradient...) that you cannot control, you have different color tones, etc... So depending on the GPU/DSP, you will not have the same experience...
Also, you cannot use that method for restreaming and converting.
Then, you need some hardware specific code, which, of course we want to avoid...
And finally, for each 'API' we need a special renderer, and not use the normal ones. Which makes more code to maintain, and VLC's core team is hardly 5 persons.
Ouch, it sounds like GPUs are a royal pain to work with. (Also: this little bit of perspective makes what you guys do seem even more awesome). Thanks for the details!
jbk - Thank you (and the rest of your team members!)
Does anyone have links to who I should talk to to volunteer as an Intel gfx hw tester? Netflix+Silverlight+Win7 is using GPU acceleration for video on my netbook, it would be great to have VLC take advantage of the same.
I've wanted this feature for a while: to be able to just drag a subtitles file while VLC is playing a video and have VLC immediately start displaying subtitles from the new file.
It's a great piece of software anyway! Congratulations on the latest release.
