[gst-devel] Sink does not reach STATE_PLAYING

[Mark Nauwelaerts]

Dirk Meyer wrote:
> Hi,
> 
> The final goal is to include gstreamer in the recording part of Freevo
> (http://www.freevo.org). To test it I'm playing with some parts of
> gstreamer if it can do what we need.
> 
> Im trying to create something that can convert a mpeg ts from a dvb
> card into mpeg4 in a matroska container. For some reason it is only
> working sometimes. I have a python script and I was happy that it
> works. Later I tried a different ts recording and it does not work
> with that file. Sometimes the sink writes some bytes and just stopps,
> sometimes the filesize will keep 0 byte.
> 
> To keep it as simple as it could get I wrote the encoder again in
> C. The source can be found at http://www.sachmittel.de/encoder.c (I
> know that there are memory leaks). The strange part now is that I
> can't neven link the audio encoder (AAC) with matroska anymore. If I
> do I get "faac gstfaac.c:641:gst_faac_chain:<aenc> error: failed to
> negotiate MPEG/AAC format with next element".
> 
> Ignoring this and copy the audio as it is to matroska also doesn't
> work. 
> 
> | gstelement.c:1969:<pipeline> committing state from NULL to READY, pending PLAYING
> 
> So far so good. Everything is READY.
> 
> | gstelement.c:1978:<pipeline> continue state change READY to PAUSED, final PLAYING
> | gstbin.c:1936:<pipeline> child 'sink' is changing state asynchronously
> 
> First of all: why asynchronously? I also have other examples where I
> tried using gstreamer and it is always the sink that does not get into
> the needed states. If I add a queue before the sink, it will still
> only be the sink.

The sink changes state asynchronously as it performs pre-roll.
That is, roughly, it will be "in-between" states (READY/PAUSED) until it finally
gets some data, at which time it can reach PAUSED.  In this state, it will
hold/block the pipeline until set to PLAYING, and then streaming/running happens
normally.

> 
> | gstelement.c:1995:<muxer> completed state change
> | gstbin.c:1931:<pipeline> child 'muxer' changed state to 3(PAUSED) successfully
> | gstelement.c:1995:<vqueue> completed state change
> | gstbin.c:1931:<pipeline> child 'vqueue' changed state to 3(PAUSED) successfully
> | gstelement.c:1995:<aqueue> completed state change
> | gstbin.c:1931:<pipeline> child 'aqueue' changed state to 3(PAUSED) successfully
> | gstfilesrc.c:906:gst_file_src_start:<source> opening file zdf-old.ts
> | gstfilesrc.c:906:gst_file_src_start:<source> opening file zdf-old.ts
> | gstelement.c:1995:<demuxer> completed state change
> | gstbin.c:1931:<pipeline> child 'demuxer' changed state to 3(PAUSED) successfully
> | gstelement.c:1995:<source> completed state change
> | gstbin.c:1931:<pipeline> child 'source' changed state to 3(PAUSED) successfully
> 
> That's it (regarding state changes). The sink claims to be
> asynchronously changing the state, but does not reach it. This means
> the whole pipeline will never be ready. 

If the above output is all there is, then missing part seems to be any
announcement of pads being created by flutsdemux (and subsequently connected).
If this indeed does not happen, nothing ever gets into matroskamux, and the
filesink for that matter, which explains why it does not make it into PAUSED state.

As far as I understand/recall, it can also make sense that flutsdemux does not
create any pads, due to lacking data (about PIDs) in the dvb recorded stream.
As such, it might only do so when it explicitly given some PIDs to its "es-pids"
property.
[btw; one can notice this by setting an appropriate debug level on flutsdemux,
in which case it will report what it runs into]

If, on the other hand, the above output is but an excerpt and pads are
definitely being created and linked, then I would not know ...

In any case, you could use an identity element just before the sink (or
elsewhere) and have it report what is passing by, if anything.  That way you may
find out where the pipeline is "being obstructed" (and why nothing makes into
the file(sink)).

Mark.