[gst-devel] Sink does not reach STATE_PLAYING

Dirk Meyer dischi at freevo.org
Wed Feb 21 20:13:07 CET 2007

"Zaheer Merali" wrote:
>> > 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.
>> Thanks, identity shows the problem. Setting 'single-segment' does not
>> help but setting 'check-perfect' shows
>> | identity gstidentity.c:329:gst_identity_check_perfect:<vident> Buffer not time-contiguous with previous one: prev ts 0:00:01.603644889, prev dur 0:00:00.040000000, new ts 0:00:01.523644889
>> This does not look good. Do I read this correct: the new buffer is
>> before the old one? This will explain the problems I have. The
>> question is why. Maybe a bug in the demuxer?
> Have you tried using the fluendo mpeg demuxers?
> They are free software and available at:
> https://core.fluendo.com/gstreamer/trac/

I tried, I don't get the pads for the stream. pad-added is not


A black cat crossing your path signifies that the animal is going somewhere.
                -- Groucho Marx

More information about the gstreamer-devel mailing list