[gst-devel] Media types database

[Wim Taymans]

On 07 Feb 2001 16:14:55 -0800, Myers Carpenter wrote:
> I'm not a c programmer.  I am a web programmer (php, etc.).  So I've been 
> trying to think of ways to add to this project.
> 
> I've been kicking around the idea of doing a media type database, with the 
> idea of listing codecs (mpeg1, sorenson), transport protocals (rtp, rtsp), 
> and file formats (ogg, quicktime), along with links to implementations and 
> specs, as well as user comments.

I like the idea a lot.

> 
> The second part to this project would be to having a database of 
> implentations of all these.

I'm quoting a piece of a random idea by Omega:

Plugin Registry:
Have a web-accessible database of plugins from everywhere, including
their merit values.  gstplugin.c
and the autoplug code (should we abstract out autoplug into a special
file?  I think so) can make use of
this database via another module (gstwebregistry.c?) to look up stuff.
A copy of the registry (gzip'd
XML) could even be cached.  System and user options would determine
whether this registry is checked
and/or updated automatically.  The registry could simply be merged with
the local machine and user
registries, with the state bit set to "don't even have it".
Autodownload/install code should be
provided, though designed such that it's not toolkit/OS specific.

Merit:
Plugins and even type definition should carry merit values, allowing the
system to determine which
plugin or type definition is better.  This can be tied into the web
registry setup, where merit values
can be updated without requiring an update of the plugins themselves.
They can also be guaranteed
unique if there's a range reserved for registered objects.
Unfortunately, that might get us into some
political wars.  We could leave that up to the users via some voting
system.

> 

> My overall goal is to get all more people thinking about converging their 
> code into fewer, richer projects (or at least make the lower levels of 
> thier code more accessable to outside projects).  It's annoying me to no 
> end as I poke my nose in all these mailing list and see that basicly 
> they're are coming up with the gstreamer concept over and over.  (eg. The 
> OpenH323 project just today started kicking around the idea of binary 
> modules to get around licensing woes.  Libmedia acutally mentions gstreamer 
> as something it's trying to emulate.  Ok, why not just work with us?).

I would love to see somebody step up and advocate the use of GStreamer
for all those
projects... Writing codecs isn't all that hard, getting a framework to
support those codecs is
another matter were GStreamer currently excels. We before we can start
to actively promote
GStreamer as a framework we still need to implement quite a few things
(dynamic scheduling,
caps negociation, seeking framework, dynamic autoplugging, possibly
gobject, etc..). 

> 
> Here is where I could use some input:
>   - a better name for the project?  "Media Type DB" doesn't really work, 
> but it's the best I've come up with so far.
>   - comments on this database structure:
> 
> media_types: 
> id, name, type (ie codec, transport, filetype), description, patented (is 
> it covered under a patent or not)
> 
> urls: 
> id, url, title, description, media_type_id
> 
> comments: 
> (slashdot type comment table)
> 
> I realize this could get much more complicated, but I'm trying to keep it 
> simple.
> 
> My plans are to host it on gnumedia.org (one of my domain names) along with 
> a news site.
> 
> thanks,

Wim

> 
> myers
> 
> 
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> http://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>