[gst-devel] Sink does not reach STATE_PLAYING

[Mark Nauwelaerts]

Dirk Meyer wrote:
> Mark Nauwelaerts wrote:
>> Dirk Meyer wrote:
>>> | 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.
> 
> OK, so when the sink needs at least one byte and it will go into the
> next state.
> 
>>> | 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.
> 
> No, that is not everything. I tried to keep to much spam out of this
> mail. The demuxer creates two dynamic pads, one for video and one for
> audio. The "funny" part is that the same logic works when using the
> Python bindings. With the Python code I have one ts file that can be
> transcoded completly and many others that only about 100kb and after
> that nothing happens anymore and I have no idea how to debug this. The
> C code was a way to find the bug ... that did not work.
> 
> The complete log is now at www.sachmittel.de/level3.log and level4.log
> (the later ist about 35MB).
> 
>> 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]
> 
> I have some debug in the code (http://www.sachmittel.de/encoder.c) to
> show new pads. I'm sure I get both audio and video pads from the ts
> demuxer. 
> 
> I have the feeling that all this is totally random. It works in python
> with some files, in C it does not work. I also had the effect that
> adding a data probe callback made it stop working. In Python I can
> connect the AAC encoder with matroskamux, using C I can't. Same
> machine, same video files.

The C code does not link the encoders to the muxer.
There should be a
gst_pad_link (srcpad, sinkpad);
in both the audio and the video section.  Adding that, the pipeline runs.

Doing a few tests (with my transcoding app, which builds a decodebin based
pipeline pretty much as yours), I have not had any randomness, and pretty stable
results (at least well exceeding 100kb) with dvb recorded input streams
(using ffdemux_mpegts btw; I had wrongly assumed before you were using
flutsdemux).  It need not absolutely follow it will work ok with all files,
though, I suppose.

Mark.