[gst-devel] Sink does not reach STATE_PLAYING

[Zaheer Merali]

On 2/20/07, Dirk Meyer <dischi at freevo.org> wrote:
> Mark Nauwelaerts wrote:
> > 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.
>
> 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?
>
> > - 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
>
> It is the muxer. Dumping both streams (audio and video) into files
> work and muxing after demuxing without encoding also does not work. So
> it looks like either my stream is buggy or the demuxer. Since every
> DVB set-top-box and all mplayer (except VLC) can play the file, I
> guess it is the demuxer.
>
> >> 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).
>
> OK, so right now I can not read the device directly with gstreamer and
> even if I could, the demuxer doesn't work on the stream. This means
> right now that gstreamer can't be used at its current stage for live
> encoding of dvb recordings for Freevo. But a normal record works, that
> is a start (we have our own TS splitter and DVB tuner). And recording
> using v4l works, too.
>
Have you tried using the fluendo mpeg demuxers?

They are free software and available at:

https://core.fluendo.com/gstreamer/trac/

Take Care

Zaheer