[gst-devel] 2 questions: threading and faad

[franchan]

Hello,

Thanks for sharing your insights!
>> 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...

Well, I was inaccurate about that, the problem popped up in the paused
state indeed.
But by then the email was already send already.

I'm not sure why it would be wrong doing it in the PAUSE state.
Although I don't work long with gstreamer,
it simple state model makes sense to me:
READY state: don't make contact with server's yet but have allocated
as much resources as necessary.
PAUSE: ready for playing as soon as state changes to PLAYING.
So by going from READY to the PAUSE state,
it should start connecting to the network, get initial content to do
typefinding.

It would be nice if also in PAUSE transition,
the playbin buffering mechanism would be in place already,
so that the whole gmain_loop does not block in a "read()".

> Ah, you're right. Sorry about that, franchan. Wim: we should think
> about a fix for that, though probably for 0.11?
>
> So: yes, apparently we do typefinding from the main thread, if we're
> in pull mode. That's unfortunate. However, it doesn't work this way in
> push mode. Since I recommended using push mode _anyway_, that's not
> too bad - you'll just need to change your plugin to work in push mode.

Perhaps I should use another demuxer
(now this was auto selected by playbin for the h264/AAC content)
or use some API I did not find yet?
At first I started with a progressive download plug-in for push operation.

Then I found qtdemux refused to seek with this source plug-in.
I made these conclusions back then when reading and tracing qtdemux.c
(I write just what I remember from last weeks so I might miss)

qtdemux_sink_activate_pull() sets its data member demux->pullbased=true.
gst_qtdemux_handle_src_event() checks this data member
in case of a GST_EVENT_SEEK event.
And it concludes with GST_DEBUG_OBJECT (qtdemux, "cannot seek in
streaming mode")
if pullbased is false.

qtdemux_sink_activate_pull() resets the pullbased flag when
the qtdemux_sink_activate() concludes through the gst_pad_check_pull_range()
that the source plug-in was push only because it missed a
_check_range_get() function,
typical for pull plug-ins ... so I thought ...

So I decided to rewrite my plug-in at that time to not use a push model.
I was surprised to see this demux code because gstreamer's documentation,
seems to favor push operation, as you also tell here ...

> There are a number of other network sources that operate in push mode
> and support streaming (e.g. the http sources), those might be useful
> examples for you.
Well, I looked into the soup/neon based http source plug-ins,
but these are complicated :-)
Now the pull based plug-in is very simple
(note that the HTTP downloading work is outside this plug-in
and based on legacy code).

For now the easiest for me is to have a delayed "PAUSE/PLAY".
Once the legacy code tells me that it has a fair amount of buffered data,
I put the pipeline into the PAUSE/PLAY state and
typefinding phase can likely finish correctly.
(I'm just afraid, how much data do I need exactly.
But that's a completely different problem)
For now about 300K seems to be enough to get the pipeline rolling ...
(moov bag in front of the mp4 file of course)

Thanks,
franchan