[gst-devel] Sink does not reach STATE_PLAYING
manauw at skynet.be
Thu Feb 15 00:02:10 CET 2007
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
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.
- 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
(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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 13541 bytes
Desc: not available
More information about the gstreamer-devel