[gst-devel] 2 questions: threading and faad

[franchan]

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.

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

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

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?

Thanks,
franchan