[gst-devel] Gstreamer vs Vlc ????

[Sean McNamara]

On Sat, Jan 15, 2011 at 9:30 AM, Shamun toha md <shamun.toha at gmail.com> wrote:
> Hello,
>
> I am getting confused with VLC and Gstreamer.
>
> Please have a look ex:
> http://images.videolan.org/images/documentation/global-diagram.jpg
> - http://wiki.videolan.org/Codec
> - it works in Windows/Mac/Linux/Xyz...
> - What is the benefit using gstreamer compared to vlc ?
> - Also gstreamer need to be ported in mac manually, we dont have officially
> 1 that is prepared to just give someone

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

>
>
> Can some one kindly share some thoughts.
>
>
> Best regards
> Thank you
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>