[gst-devel] Sink does not reach STATE_PLAYING

[Dirk Meyer]

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.


Dischi

-- 
This message was sent to you via email in much the same way bricks
aren't.