[gst-devel] Sink does not reach STATE_PLAYING

[Mark Nauwelaerts]

Dirk Meyer wrote:
> Mark Nauwelaerts wrote:
>>> 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.
> 
> Arg, stupid bug. Thanks. I was so busy trying to find out how the C
> API works and how to get the pads, I forgot to link them.
> 
> Now I get STATE_PLAYING but it stops. When doing no encode/decode
> (copy the ts data to mkv) I get:
> 
> | WARN           matroskamux matroska-mux.c:1721:gst_matroska_mux_write_data:<muxer:video_0> Invalid buffer timestamp; dropping buffer
> 
> And a little bit later everything stops. Or let me say blocks, I don't
> get any more errors. When doing the recode it works for the file that
> also works using my other script written in Python. A different file
> starts the transcoding and stops some seconds later without any
> warning. Using debug level 3 I see the GST_EVENT
> gstevent.c:532:gst_event_new_new_segment_full about 20 times and
> that's it. Any idea why this could happen?

Muxing pipelines can (and typically will) stall/block if their inputs'
timestamps do not form a nice(ly balanced) continuous stream.  This may possibly
be going wrong in both cases, e.g. invalid/unknown timestamps in the former
case.  In the latter case, such newsegments normally come from demuxers (dealing
with time-gaps), though the ffmpeg based one is not written to send (many of)
these (AFAIK), and I am not that much into the TS format or its demuxers.

>> Doing a few tests (with my transcoding app, which builds a decodebin
>> based pipeline pretty much as yours),
> 
> I tried decodebin in Python and it did not work. Using the
> ffdemux_mpegts without the decodebin it worked better.
> 
>> I have not had any randomness, and pretty stable results (at least
>> well exceeding 100kb) with dvb recorded input streams (using
>> ffdemux_mpegts btw;
> 
> What is this app? Is it a small sample you can give me or a huge piece
> of code or closed source?

It is, or rather will be, very open in a month or so, as it still in its "final"
polishing.  It is not that small, so not very easy/instructive to get pieces out
of it.  For what is relevant in this case, however, it is essentially basic
decodebin based plugging.

>> I had wrongly assumed before you were using flutsdemux).
> 
> I tried that, too and also had problems with it. I had good results
> using the ffdemux_mpegts but when I tried more files it also
> failed. Maybe I should start playing with decodebin or flutsdemux
> again, but I'm not sure this would solve my problems.

Mark.