Using appsrc with infrequent buffers

Tim-Philipp Müller t.i.m at zen.co.uk
Wed Sep 11 06:30:30 PDT 2013


On Wed, 2013-09-11 at 16:32 +1200, Adam Goodwin wrote:

Hi,


> But while investigating the matroskamux anyway, I think I've found the
> problem, Instead of even having the appsrc connected to the muxer,
> I've changed the pipeline so that the matroskamux only has one sink
> pad (for the video). I also have the appsrc still, but I've connected
> it to its queue element and then a fakesink (instead of the queue then
> the matroskamux).
> 
> 
> What I'm seeing is the same problem. The receiver application looks to
> not be getting anything from over RTP, and the MKV file still has most
> of the video missing along with other glitches. The appsrc simply
> being present in the pipeline is enough to mess things up.

Have you tried with fakesink async=false ? (though that should not be
necessary really).


> However, manually giving the appsrc data alleviates the problem as
> before. I now realise that there isn't anything wrong with the RTP
> section of the pipeline. What seems to be happening is that when the
> program starts, the keyframe from the camera (i.e. the  H.264 I-frame)
> is produced before the appsrc pushes any buffers. It seems that the
> appsrc holds up the entire flow of the pipeline somehow, so that the
> video stream - up until the first appsrc push - is lost. So the
> receiver doesn't start displaying the RTP stream until the next
> I-frame comes through which can take some time.
> 
> 
> Going back to my original pipeline, with the appsrc connected to a
> subtitle pad of the matroskamux, I was able to produce a reasonable
> MKV file which VLC could play - including with my subtitles (albeit
> with a few hiccups of missing video still). All I had to do to get the
> better result was feed in a line of text to the appsrc quickly enough
> after the application started running. I also had to keep feeding
> lines into the application from stdin, without too much time between
> each line, as leaving too long a gap seems to be when things start to
> go really wrong.
> 
> 
> So the root problem seems to be that if appsrc goes too long without
> pushing a buffer, the whole flow of data in the pipeline is stopped.
> Even with all my branches having queues which I thought would avoid
> this sort of global hangup.
> 
> 
> 
> So absolutely it seems like your fix of gap events will work, or if
> not I can just make sure to give some nonsense subtitle buffers to the
> appsrc instead of generating events. In particular I'll have to make
> sure a buffer is pushed the instant the pipeline starts to play, so as
> not to lose the first video buffers. But my real question now is if
> this behaviour of appsrc is a bug? It certainly doesn't seem like
> appsrc should be able to hold up the whole pipeline whenever it hasn't
> had any buffers for a while - especially when all my branches have
> queues in order to avoid this type of problem. But then again, it's
> possible that there's something I have configured wrong in my
> application. Any ideas on this?

It's not the appsrc itself, it's likely the sink or muxer, waiting for a
buffer.

It would generally be helpful if we had a better idea about your
pipeline, maybe you could dump the pipeline to a dot file and generate
an SVG from it or so?

Cheers
 -Tim




More information about the gstreamer-devel mailing list