[gst-devel] Sink does not reach STATE_PLAYING

[Mark Nauwelaerts]

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

It may help inserting an identity element (which dumps information on passing
buffers, such as the timestamps they have), and checking for a particular
pattern of difference (?) between the success and fail cases.  As said before,
if these timestamps are "not nice", things tend to stall after a very short time
(and one can't really blame a muxer/pipeline in that case).  Inserting an
identity with single-segment property TRUE (before encoder) might make it to
re-sequence the timestamp to something more suited/balanced, if this were the
problem in the first case.

Notes:
- this is pretty much assuming it does stall "in/around" the muxer, which
could be tested by not connecting to the muxer, but e.g. each to a fakesink,
which should then keep the pipeline going.  If it does not, ffdemux_mpegts or ??
somehow gets confused at the source ??, would have no idea
- identity might not manage to re-sequence if the input stamps are too
wild/screwed, in which case they may have to be re-sequenced manually, i.e.
"count-based", as a desperate last resort  (I have some simple custom element
around that can do so, but have not yet had to use it; rough version attached)

> 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?

That is the essential difference; in pull mode the ffmpeg demuxer expects to
have a seekable input, in push mode it will have to make do with "piped input".
Feeding ffmpeg demuxer this way is not yet implemented in gst-ffmpeg cvs, but
there is a patch to implement this in
http://bugzilla.gnome.org/show_bug.cgi?id=392534
(patch http://bugzilla.gnome.org/attachment.cgi?id=79694 to be precise).

>>>> 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.

Quite possibly; decodebin will only use elements in its autoplugging whose
factory have a rank (as a plugin feature) that is at least MARGINAL (64).
gst-inspect shows ffdemux_mpegts to have rank None (0), so it would not be
considered.  Rank can be changed using gst_plugin_feature_set_rank (on the
proper element factory), and then it should be OK  [I overlooked this earlier as
I got used to having some configuration that takes care of this].  Also "watch
out" here for the rank of flutsdemux that may also be around (in your
installation).  Alternatively, you can also have a look at decodebin2 that may
allow for other configurability.

Mark.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gststatus.c
Type: text/x-csrc
Size: 13541 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20070215/fa3bc415/attachment.c>