<div dir="ltr"><div><div><div><div><div><div><div>Thanks a lot, I didn't know about gap events - I'm looking into generating these periodically now. I'm thinking of probably using g_timeoout_add_seconds() and getting the callback to call gst_element_send_event() for the appsrc, hopefully this is an acceptable approach.<br>
<br></div><div><br></div>More interestingly, I've just tried something else though. I thought about what you said, but if the problem is in the muxer, then I couldn't work out why my pipeline's RTP branch is being held up by the appsrc being connected to the muxer. With all the queues I have, I would have thought any hangups would be restricted to just the appsrc and muxer.<br>
<br>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).<br>
<br></div>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.<br>
<br></div>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.<br>
<br></div>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.<br>
<br></div><div>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.<br>
</div><div><br></div>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?<br>
<br>Thanks<br></div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Sep 11, 2013 at 3:33 AM, Tim-Philipp Müller <span dir="ltr"><<a href="mailto:t.i.m@zen.co.uk" target="_blank">t.i.m@zen.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2013-09-11 at 03:10 +1200, Adam Goodwin wrote:<br>
<br>
Hi,<br>
<div class="im"><br>
> (sorry to keep asking for help so much :/).<br>
<br>
</div>Not a problem, that's what the list is for!<br>
<div><div class="h5"><br>
<br>
> I've still got my H264 streams going from cameras into a matroskamux<br>
> (and one stream being sent over RTP). At the moment I'm working with<br>
> only one v4l2src, because this seems to work stably for me, so there's<br>
> only one video stream.<br>
><br>
><br>
> I've now added an appsrc which I've hooked up to the a subtitle pad on<br>
> the matroskamux. I haven't put together the subtitle retrieval at the<br>
> playback side of things, but the appsrc seems to be working when I<br>
> push buffers (none of my error checks come back with anything).<br>
><br>
><br>
> However:<br>
><br>
><br>
> My video doesn't seem to be sent over RTP unless I type a line of text<br>
> into my application - which causes the appsrc to push a buffer (with<br>
> the text forming a subtitle). Once I've typed a line, I start to see<br>
> video in my RTP receiver application. However, it quickly comes to a<br>
> stop again until I type more. So it appears the pipeline doesn't like<br>
> it when appsrc isn't contributing.<br>
><br>
><br>
> As well as this, if I play my resulting MKV in VLC, the playback is<br>
> completely messed up. Whole sections of video are missing (or maybe<br>
> sped up so much that they're essentially skipped), and the progress<br>
> bar skips around all over the place. Despite this, I did see my appsrc<br>
> subtitles displayed by VLC a few times. So it suggests to me that<br>
> there are timing issues in the pipeline, and that it's not necessarily<br>
> anything to do with the appsrc related stuff (although it was adding<br>
> the appsrc that triggered these issues, which are somewhat similar to<br>
> those I was having when a second camera is introduced). Is it possible<br>
> that the matroskamux is having issues with multiple input streams?<br>
<br>
</div></div>The problem is likely in the muxer (or rather the GstCollectPads<br>
functionality it uses internally). It might wait for a buffer on all<br>
pads before continuing / doing something.<br>
<br>
You might be able to work around this by pushing a GAP event on the<br>
subtitle appsrc whenever you know that there won't be any subtitle data,<br>
or when there hasn't been any sub data for the last second or so. That<br>
should hopefully keep the muxer ticking along.<br>
<br>
Cheers<br>
 -Tim<br>
<br>
_______________________________________________<br>
gstreamer-devel mailing list<br>
<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel</a><br>
</blockquote></div><br></div>