[gst-devel] Using buffering for progressive download

[franchan]

Hello,

I have a question regarding
- playbin's handling of the buffering (0..100%) messages,
- pausing the pipeline as a consequence and
- prerolling.
Most pipeline elements in my case (source, demuxer, video and audio decoders)
are home made, based on proprietary parsing and decoding libraries
(so these might have "irregularities" because my lack of gstreamer).
playbin is used to construct the pipeline.

During progressive download, I receive the synchronous "buffering" message.
I then pause the pipeline with gst_element_set_state()
(in the context of the synchronous message thread, that's OK I guess).

During this buffering pause state, I notice that normally
the demux's loop and video decoder's chain keeps running at full speed.

Sometimes I never receive the final buffer message 100%.
I don't understand why that is.
This typically happens frequently when the gstreamer's logging limited.
So I never know when to put the pipeline back into the playing state again.

When I open up a debugger and check the state of all the threads,
I see that all gstreamer related thread are blocked.
One is hanging in gstbasesink's gst_base_sink_wait_preroll() on
GST_PAD_PREROLL_WAIT.

According to the source this should be signaled with a flushing or
a state change from pause to playing.

Now I wonder, might it be the buffering mechanism that has put
everything in pause?
Or is this likely a bug somewhere in the proprietary elements?
For instance caps not done properly?
Do you have a suggestion on what to investigate next?

Thanks,
francis