[gst-devel] 2 questions: threading and faad

[Wim Taymans]

On Wed, 2008-09-10 at 08:28 -0700, Michael Smith wrote:
> On Wed, Sep 10, 2008 at 12:50 AM, franchan <francis.meyvis at gmail.com> wrote:
> > Hello,
> >
> > I'm using a playbin base pipeline.
> >
> > Initially I thought gstreamer was running in its own thread context.
> > But after setting the state to GST_STATE_PLAYING from the main thread context,
> > I get the impression that I only return from the call,
> > when the typefinding procedure has finished.
> 
> This is incorrect, typefinding is never done from the main thread.
> It's possible, of course, for buggy plugins to make setting the
> pipeline state block - some of the http sources have bugs like that.
> Since you're writing your own source, I'd guess the problem is there.
> 

The typefind element does typefinding in the state-change to PAUSED.
This is arguably the wrong thing to do but it's currently done like that
because we otherwise would need a scheduling mode switch from the
streaming thread. I'm not quite sure how that would work...

Wim

> 
> >
> > My source takes it content from the internet (kind of progressive download).
> > And I inform this source plug-in each time more data is available from
> > the main thread.
> >
> > The source plug-in presents itself as a pull source because
> > I support seeking in the downloaded part.
> > And the qtdemux requires its source to operate pull based.
> > (don't know if this pull is relevant for my question here).
> 
> That's probably not a good idea. qtdemux works fine in push mode, and
> you can support seeking in push mode if you want.
> 
> >
> > When the source is asked for data but the plug-in sees there's not enough,
> > it blocks in a sleep (or returns an error and
> > certain type finding that is not relevant fails e.g. apetag).
> >
> > Because this all happens in the main thread content,
> > I cannot inform the source plug-in that new data did arrive.
> > And so type finding halts waiting for data (that is there actually).
> 
> This doesn't happen in the main thread, so you've diagnosed the
> problem incorrectly.
> 
> >
> > Is my conclusion right?
> > If so, why does the typefinding phase not use
> > the normal playbin buffering mechanism
> > and informs when to pause/play the pipeline for cause of buffering.
> >
> > I likely have to make sure the PLAY_STATE is only set
> > after enough data is downloaded for doing a successful type finding?
> > Or do you know another work around?
> >
> > My second question is regarding faad.
> > I tweak the configure script of the bad plug-in to accept the faad-library
> > installed on my platform and it seems to work well.
> >
> > Yet I get a feeling faad is not welcomed in gstreamer.
> > What is the reason for this?
> > Some people prefer to make a new AAC decoder and a plug-in?
> > Is it impossible to fix faad?
> >
> 
> The FAAD library is mostly unmaintained, and is generally not very
> nice to use. If someone were to step up and maintain it properly, and
> the gstreamer plugin, and add appropriate tests and documentation, we
> would be happy to move it to gst-plugins-ugly - all plugins have the
> same criteria for being moved out of -bad.
> 
> Mike
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel