[gst-devel] typefind and modifying a running stream (python bindings)
dlenski at gmail.com
Tue Sep 11 03:42:47 CEST 2007
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!
More information about the gstreamer-devel