31–40 of 61 posts
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).
Earlier quoted context omitted.
No, it is doing it fine. The irony is that if you have an Intel SSE4.1 chip, you can use a special trick to work-around this "bug".
Where's the "irony" in that? Or did you perhaps mean something else?
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.
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.
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.
Yes. I wonder why the built-in update never works. It gave me the message while updating 1.0.5 that it is the latest version.
Earlier quoted context omitted.
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/cann…
(I can explain if needed...) 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.
Earlier quoted context omitted.
No, it is doing it fine. The irony is that if you have an Intel SSE4.1 chip, you can use a special trick to work-around this "bug".
Where's the "irony" in that? Or did you perhaps mean something else?
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?
