[gst-devel] Sink does not reach STATE_PLAYING

[Dirk Meyer]

Mark Nauwelaerts wrote:
> Dirk Meyer wrote:
> 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.

The transport stream has timestamps directly from the DVB source. So
they don't start with 0, I guess that is the reason why newsegments
are created/send/whatever. Only a guess.

I did some more recordings and tried them. I have about 20% of my
files that just work and the 80% stop after 1 or 2 seconds of
transcoding. I have no idea why or what part of the chain stops
first.

I also tried to read directly from the device (later there will be a
ts splitter we wrote, but let us keep this simple). Doing this I get

| ffmpeg gstffmpegdemux.c:1305:gst_ffmpegdemux_sink_activate_push:<demuxer> error: failed to activate sinkpad in pull mode, push mode not implemented yet

I have no idea what that means. The difference is that the file is now
unseekable because it is the device. What does this error mean and how
can I work around it?

>>> 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 just tried the decodbin again. The signal new-decoded-pad is never
emited and because of that I never can connect stuff.


Dischi

-- 
Education is what you get from reading the small print; experience is
what you get from not reading it.