Getting the mime-type of content returned by httpsoupsrc?

[Sebastian Dröge]

On Di, 2014-05-06 at 17:54 +0100, Tim Müller wrote:
> On Tue, 2014-05-06 at 12:25 -0400, Stirling Westrup wrote:
> 
> Hi,
> 
> > I'm working on a program that can handle a number of different input
> > formats, and I am wondering how to handle the remote fetching of URLs.
> > 
> > If someone hands me a location of http://www.foo.com/content
> > 
> > I can't know for sure if I'll get back a web page, a jpeg, an .mp3 or
> > what. In each case I'll need a different pipeline, of course.
> > 
> > Now GStreamer has a typefind system for this kind of issue, but I'm
> > not sure how to hook it to httpsoupsrc.  The 'typefind' property of
> > that element doesn't seem to do anything that I can detect, and I'm
> > not sure how one otherwise sets up a typefinder. So far I've just
> > relied on decodebin.
> 
> You could just put a 'typefind' element after the source, and then
> connect to the 'have-type' signal (to plug further elements), which is
> what decodebin does.

Also note that the mime type as reported in the HTTP headers has not
(necessarily) anything to do with the caps at all. Even for simple cases
like "audio/mpeg" (mime type) it wouldn't work as GStreamer caps because
that could be MP3 or AAC or any of the other layers of MPEG 1 audio.

However I'm thinking of adding a feature to souphttpsrc, that will cause
it to push a custom event with all the HTTP headers downstream before
the data flow... so that downstream elements can extract whatever
information is interesting to them out of the headers. If that helps
anything in your use case...

-- 
Sebastian Dröge, Centricular Ltd - http://www.centricular.com
Expertise, Straight from the Source
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20140506/1e667a2d/attachment.sig>