[gst-devel] Getting mindshare
Wim Taymans
wim.taymans at chello.be
Fri Aug 18 22:18:11 CEST 2000
"Myers W. Carpenter" wrote:
>
> Wim Taymans wrote:
> > My current goal is to have a real programmers manual, polish some stuff and
> > start to promote things rather aggresively.
>
> Wim Taymans: Not only does the man hack code, he can actually document
> stuff too :).
>
I can't. You know, I do this all the time at work, but I find myself being very
bad
at it...
>
> > libAV must be merged. And that shouldn't take more than a few weeks.
>
> Since we never wrote any code, I think it's merged now :).
Oops, I confused libDV... *slap*
>
> Right.... did you ever metion to the avifile guy about joining up with
> our project? Maybe we should try for the guy who did xmps too.
I'll write a mail to the avifile guy now. I'll let you know.
>
> I think we should keep the core only tied to glib. I know we are tied
> to gtk right now because, but like it says on our homepage it's only
> because the object model framework is in gtk and will be moved to glib
> in the next version.
> I don't know if the KDE guys would be at all intrested in this given
> it's in C and uses glib, but it would be nice to be open.
> I also want to build a videowall with this project, by sticking as many
> cheap Video cards with TV Out in a computer and have gstreamer split up
> the image and output to framebuffers attached to each card.
> There isn't really a good advantage that I can see by binding the core
> of the project to X/Gnome/Bonbo.
No, I agree about the core, but you are going to have to decide if you are
writing
a real app.
Also gnome-mime is very attractive... I'll end up reimplementing it...
A bonobo wrapper around gstplay is also very attractive...
A capplet to configure the codecs, GConf for storing the config... The capplet
can be written seperatly from the framework. GConf is out of the question, we
probably want to use real text files.
>
> That would work too. How close are we to a real DVD player in
> software? I know we check for DeCSS code in our config script, but does
> that actually work? Maybe we can even get the oms guys working on this
> too.
No IFO parsing yet and I do not have a DVD-ROM so I cannot test DeCSS. Otherwise
Things are quite complete, expect for frame skipping...
We also do not have a multifile src to concatenate the different VOBs. Audio
is not downsampled to the max frequency of the audiocard yet... gstplay has no
GUI for selecting the subtitle or audiostream.
This is like the current state of GStreamer: a big and very tasty pie, but
without
the cream on top, yet :-)
>
> Sounds good. I think getting end users on board as quickly as possible
> would be great.
>
> One thing is that I wonder if we could have the option to compile in
> all the LGPL'ed codecs in to one big lib, to step up the loading time.
hmm... I prefer something scalable without loading all the stuff at once..
>
> BTW, would it help at all to point out all the bugs I run into in
> gstplay? Perhaps on the bug report on sourceforge.net?
>
Gstplay is a hack. I plan a rework someday, but you can post a bug report here..
> > - for the end user: no QoS. just one app.
>
> By QoS you mean we don't drop frames when it's too slow?
Yup. definatly needed..
> > - just a few native avi codecs.
>
> No quicktime. Make use of the xanim codecs somehow.
xanim is horrible. libquicktime is better though... Like I said, I can spend
the rest of this year porting codecs :-)
>
> I too can't meet on IRC (I'm on the east coast, but I'm making just as
> long of trip :).
Some other time...
Wim
--
There is no likelihood man can ever tap the power of the atom.
-- Robert Millikan, Nobel Prize in Physics, 1923
More information about the gstreamer-devel
mailing list