[gst-devel] Sink does not reach STATE_PLAYING

[Zaheer Merali]

On 2/21/07, Dirk Meyer <dischi at freevo.org> wrote:
> "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
> called.
>
>
> Dirk
>
> --
> A black cat crossing your path signifies that the animal is going somewhere.
>                 -- Groucho Marx
>

Do you include the PAT and PMT in your transport stream that you are
trying to demux?

If not, then you need to specify the elementary stream pids with the
parameter es-pids

eg. flutsdemux es-pids=1234:1235

if the elementary stream pids are 1234 and 1235 for example.

Zaheer