relaxing rtp packet probation

[Aleix Conchillo Flaqué]

Forgot to mention that other options would be:

- analyze, let's say, 10 packets, sort them and check for sequence numbers.
- simply disabling the probation as requested by the user.
...

Another question would be is the probation really necessary?

Thanks,

Aleix

On Tue, Aug 21, 2012 at 2:50 PM, Aleix Conchillo Flaqué
<aconchillo at gmail.com> wrote:
> Hi,
>
> I am streaming (via rtp) jpeg images every 4 seconds and everything
> worked fine until network latency jitter was setup (using tc command).
> The server is implemented with gst-rtsp-server and the client simply
> uses rtsprc element.
>
> Digging around rtp code I found out that
> gst-plugins-good/gst/rtpmanager/rtpsource.c does a probation to
> determine if we have a valid RTP stream. Until that probation succeeds
> no packets are pushed to other elements.
>
> The current probation algorithm expects receiving a couple of sets of
> 2 packets with consecutive sequence numbers. The problem with my jpeg
> stream and network configuration is that it sends few packets every
> time and none of the packets have consecutive sequence numbers. This
> means that the probation will always fail. Setting a higher latency
> does not help as the probation is done even before the
> gstrtpjitterbuffer receives the packets.
>
> Attached, there's a patch that relaxes that probation a bit by adding
> a threshold. So, it expects a couple of sets of 2 packets with
> consecutive numbers considering a threshold of 2, thus receiving a
> packet with sequence number 3 and then a packet with sequence number 5
> is considered valid.
>
> I am new to this code, but the patch actually works. I am probably
> missing lots of things here. So any help would be appreciated.
>
> Thanks in advance,
>
> Aleix