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

[cascardo at holoscopio.com]

Please, don't send a reply to my e-mail. I'm subscribed to the list.

On Thu, Oct 05, 2006 at 07:27:22AM +0200, Zaheer Merali wrote:
> On 10/5/06, cascardo at holoscopio.com <cascardo at holoscopio.com> wrote:
> >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.

That would be fine for choosing whether to dispatch Totem ("video/ogg")
or Rhythmbox ("audio/ogg"). However, that would be two different types
for a format that can describe itself since you know its type. You just
read the header. Don't wanna waste bandwidth? So, use the codecs
parameter for the type, like the reply to the IETF post you send refers
to.

> >>
> >> 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.
> >
> 
> Easy, use a method like Discoverer which is in gst-python (also
> includes a test program to use it called gstfile)
> http://webcvs.freedesktop.org/gstreamer/gst-python/gst/extend/discoverer.py
> 

This method requires a running pipeline and detects codecs using the
decoder element after it's plugged in. And it requires a source and is
dependant on it. What if you just wanted to get this information from
the supported types in an element?

> The capabilities in GStreamer in no way corresponds to the MIME type
> of the file.  It is used internally to identify the buffers passing
> between pads in GStreamer.  To find out information of whether there
> is video in a certain stream etc., use Discoverer as noted above.
> 

No, it does not. In fact, most file sources don't even have a MIME type.
Unfortunately, most filesystems, even when they support extended
attributes, are not formatted or mounted with this support. And if they
are, most applications won't set a file MIME-type when downloading them
and writing on the filesystem. That would be a fine feature to
GStreamer. I will write as soon as I can a derivate class from
GstFileSink and GstFileSrc (reading the MIME-type from disk and using it
to negotiate is important too, otherwise writing them would be useless).

Caps allow negotiation between elements and to tell which types are
supported by an element. Caps associated to buffers will dispatch a new
negotiation when a different caps is used. But this happens only when
you have a running pipeline and a source.

If you want to know which elements support sinking both audio and video
(but not video/ogg and audio/ogg, since they are containers), you are
screwed, because you must know every type that is a codified audio but
not a container. And if there is some type that is used for both, you
must know any property for the Structure/Caps that indicates that it is
not a container. My proposal is to have a centralized registry that
would "know" these.

> >---
> >
> >Regards,
> >Thadeu Cascardo.
> 
> Regards
> 
> Zaheer

Regares,
Thadeu Cascardo.