how is udpsink related to or dependent on videorate?

[Tim Müller]

On Tue, 2016-02-16 at 12:32 -0800, Andres Gonzalez wrote:

Hi,

> appsrc->queue->videorate->videoconvert->timeoverlay->textoverlay-
> >x264enc->rtph264pay
> (snip)
> Then if I change the pipeline and remove the videorate element from
> the pipeline, and run again, but now the pipeline is broken. The
> udpsink element for RTP pkts does not send any UDP pkts.  The RTCP
> udpsinks still function, the receiver sends RTCP RRs indicating no
> pkts received, but the sender now also sends RTCP RRs and not RTCP
> SRs. I am checking API return values and there are no bus errors, but
> without videorate in the pipeline, there are no UDP RTP media pkts
> are sent by udpsink (all of this monitored by wireshark).

The videorate should not be needed here, of course, it just 'fixes up'
your input timestamps, but in an RTP scenario that should'nt be
required really.

So udpsink doesn't send anything if you remove the videorate element.
First thing to check: does udpsink receive any buffers at all, or is
the problem further upstream? Second thing to check: what is the
segment event and what timestamps are set on the buffers it gets? Is it
waiting until later to render the buffer? Is it dropping the buffer for
some reason? Does it work with sync=false ?

GST_DEBUG=basesink:6 might shed some light in this respect (you can
probably remove the RTCP src/sink to reduce the noise in the log).

> Using gst-inspect on videorate, it appears that this element will
> only drop or duplicate to ensure a perfect stream, so I cannot
> understand why its lack of presence in the pipeline would effect UDP
> pkt generation with an element so far downstream as the RTP udpsink.
> 
> Is there a reasonable explanation for this?   perhaps an unreasonable
> explanation?  any explanation?

My guess would be that there's something off with your buffer
timestamps and videorate happens to 'fix' it.

Cheers
 -Tim

-- 
Tim Müller, Centricular Ltd - http://www.centricular.com