[gst-devel] Sink does not reach STATE_PLAYING

[Dirk Meyer]

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.



Dirk


-- 
Yesterday is history, Tomorrow is a mystery, Today is a gift. That's
why it's called: The Present.