[gst-devel] 2 questions: threading and faad

[Michael Smith]

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.


>
> 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