[gst-devel] Filtering with catch-all mime type video/*?

[cascardo at holoscopio.com]

On Wed, Oct 04, 2006 at 10:24:41AM -0700, Charles Iliya Krempeaux wrote:
> Hello,
> 
> While I do agree with you that Ogg is a container format... AFAICT using
> "video/ogg" when you know that it contain video would be correct.  And
> (based on complaints I've seen) some would highly enourage it.
> 
> I've seen some people suggesting that there should be MIME types like
> "video/rss+xml" and "video/atom+xml" for video blogging (vlogging,
> vidcasting, or whatever you want to call it).  And hints that there should
> be "audio/rss+xml" and "audio/atom+xml" for audio blogging (podcasting,
> IPradio, or whatever you want to call it).
> 
> Refer to this IETF post...
> 
> http://www1.ietf.org/mail-archive/web/avt/current/msg06669.html
> 
> ... which is (in part) a comment to the following proposal I made...
> 
> http://maketelevision.com/log/rss_and_atom_feed_auto-discovery_for_internet_tv
> 
> 
> See ya
> 

Yes, and some other container formats supported by GStreamer are (using
standard MIME types) referred as audio/sth and video/sth. And I sure
agree that using standard MIME types is right.

However, being able to distinguish between a container, a codified audio
or video and a raw audio or video should be possible. Right now, this is
not possible and I still don't know which advantages would "video/ogg"
have over "application/ogg" as the MIME type for a container, since you
can't get the difference between "video/mpeg" as a container and
"video/mpeg" as a codified video, other than by an accompanying
"systemstream" property that not every container format have.

Since using the MIME type as the name of the GstStructures held by a
GstCaps is stablished in GStreamer and MIME types won't tell us in a
generic way what it really is (either a container or a video), we should
be able to tell what it is some other way. Using a list of known MIME
types and properties is possible, but it won't help for new Elements
that can deal with new MIME types.

Would it be feasible to implement something in the registry that could
tell an application what the type is giving its MIME type and
properties? It is almost the same as the former list, but an Element or
an install procedure could add information to the registry.

I think this would not do harm to the API, other than adding some to
access this new information in the registry. Current elements need not
be modified since the needed information for their types would be
distributed or registred using some centralized method (core, plugin,
files, install scripts, tool). New elements could use this new API to
register the types they deal with.

If adding this new API and data to the registry is OK for the core
maintainers, I would be willing to work on it, with help and discussion
on this list.

Regards,
Thadeu Cascardo.