gstreamer vs VLC

转自：http://gstreamer-devel.966125.n4.nabble.com/Gstreamer-vs-Vlc-td3219107.html

This could turn into a debate like vi vs emacs, where people are 
strongly opinionated and there is never really any end to the debate. 
It might therefore be wise to do a cost-benefit analysis on your own 
and make up your mind based on your own particular requirements or 
preferences. 

Here are some of the topics of debate that would come up, which you 
did not yet mention in your message: 

1. Legality of the codec implementations. For each product, which 
codecs are available? Do they comply with the letter of the law in all 
jurisdictions where you and anyone to whom you distribute your 
software plans to use it? For VLC, I am unaware of any MPEG-LA codec 
implementation that will run on VLC that is legally licensed in the 
U.S. or any country respecting U.S. patent law. To use MPEG-4, AAC, 
WMA, H.264, or any number of other patent-encumbered codecs, you can 
either break the law; live in a country where it isn't breaking the 
law; or use legally licensed codecs. Since VLC has none, that leaves 
only Gstreamer and the codecs that you can buy from Fluendo: 
http://www.fluendo.com

2. Available plugins. I'm aware that VLC is based on a similar filter 
graph infrastructure as Gstreamer, but I think that the number and 
variety of plugins available for Gstreamer makes it more useful for 
writing applications. Gstreamer is often accessible even to new users 
because of its console commands, gst-launch and gst-inspect, which 
help people to understand how the plugins fit together before they 
develop an application. Again, Gstreamer's focus is not to deliver an 
end-user product, but to provide an intuitive API and wide variety of 
generally-useful plugins for application development. By contrast, VLC 
*is* the application, so the development focus is on using the 
existing VLC graphical interface to perform typical user tasks, like 
video playback, streaming, and conversion. Note that "available 
plugins" doesn't necessarily translate to "available codecs": there 
are a lot of Gstreamer plugins that are not a codec, and these are 
equally important as the codecs. 

3. Available codecs. If you just install the legally licensed "free as 
in freedom" codecs in Gstreamer, from gst-plugins-{base,good,bad}, 
it's clear that VLC wins the codec variety battle. But you can also 
stack a great number of additional codecs into Gstreamer by adding in 
gst-plugins-{gl,ugly,ffmpeg}, with legal strings attached, or 
gst-plugins-fluendo (the paid Fluendo codecs) without legal strings 
attached, but with a price tag attached :-). In the end, a fully 
loaded gstreamer (legal or otherwise) can more or less compete with 
VLC on codecs, but you have to either consider your legal situation 
very carefully, or disregard it entirely, which I can't recommend (but 
many people seem to do it anyway). 

4. Platform integration. It's hard for VLC to keep up here, because 
VLC is its own world. It doesn't have any familial resemblance to any 
of the popular Linux desktop environments. Gstreamer, on the other 
hand, is a well-behaving GLib-based library, and so it integrates 
quite easily into GNOME applications. So if you are thinking of using 
GLib, GTK+, etc. in your application, you have a huge incentive to 
also use Gstreamer over any other media framework, because the 
programming paradigms it uses will fit quite nicely into your overall 
app design. VLC's preferred interface uses Qt4, which should look good 
on KDE, and decent on a properly-configured GNOME desktop, but you 
still don't get that fully platform integrated feel. 

5. Performance. If you're doing a lot of data processing, or just any 
kind of processing on small hardware (e.g. embedded), you could 
actually care about performance. I won't make any claims about the 
relative performance of Gstreamer and VLC, because I don't know how it 
goes; but I do know that Gstreamer has been successfully deployed on 
mobile devices with minimal modifications. Usually it is good enough 
to just, for example, use one of the fastest settings for resampling, 
and work with integers rather than floats across the pipeline. These 
little tweaks can be made by tapping element properties before you 
play your pipeline, and make a big difference in the performance of 
the pipeline. I don't know to what extent VLC has similar options 
because I am less familiar with it. 

6. Bindings. What bindings does VLC have for developing software 
against the VLC core using non-C languages? Well, it has Python 
bindings, sure (so does Gstreamer); but what else? If you have a 
particular programming language you care about, make sure that VLC 
supports bindings for that language. If Gstreamer has bindings that 
VLC doesn't for your desired language, that might be a strong reason 
to use Gstreamer (or, alternatively, contribute new bindings to the 
VLC project!) 

7. Community. This is a hard one to quantify, or even qualify, but the 
friendliness and helpfulness of the community makes a big difference 
when I'm doing software development. I haven't worked too much with 
the VLC community, but I know that the Gstreamer community is one of 
the best in terms of being civil, providing sound advice, and being 
available over a wide array of media (IRC, email, etc.). Not to 
mention that you can get professional Gstreamer support from some 
companies, I understand ;-). 

Anyway, you may or may not agree with these assessments, but the 
_topics_ of each of those items are certainly relevant in making a 
choice between these two open source projects. This topic has the 
potential for strong words and disagreements, so I will refrain from 
replying further to this thread. Just keep in mind that this kind of 
choice is difficult to make in the general case (i.e. for all users); 
the most useful evaluation is one coming from your *own* perspective, 
focusing on your *own* requirements and preferences. My claims in this 
message are just coming from my perspective, which may be completely 
irrelevant to yours. Take it or leave it. 

HTH, 

Sean