[gst-devel] typefind and modifying a running stream (python bindings)

[Daniel Lenski]

On 9/10/07, Tim Müller <t.i.m at zen.co.uk> wrote:
> Yes, there are a few issues here.  Basically, you need to look at things
> from the streaming thread's perspective (which is: if you don't do your
> stuff in the streaming thread, it will either error out with a
> not-linked flow error, or the pipeline will preroll if there's a sink,
> but then you'll lose data if you replace the sink with some other
> element).  This means you don't rely on things like pipeline pausing,
> but you do everything in signal callbacks like new-decoded-pad,
> pad-added, type-found etc.  Otherwise you need to do pad blocking to
> avoid data loss.

Thanks, Tim!  So, as long as I modify the pipeline inside the
callbacks, I should be okay?  Is there somewhere in the gstreamer
manual that explains the details?

> application/x-id3, hopefully :)  The only correct way to identify an mp3
> stream via typefinding is to check for "audio/mpeg, mpegversion=1,
> layer=3".  Any file can have an ID3 tag, and it's not that uncommon to
> find ID3-tagged .wav or .flac files.  Some files may even have multiple
> ID3 tags, or nested ID3/APE tags.

Yes, that's it.  The problem is that if I run many MP3 files through
typefind, I get application/x-id3, and NOT audio/mpeg... is this a bug
or is there something I am doing wrong in the have-type callback?

Thanks for you help!

Dan