Dropped packets between tsparse and rtpmp2tpay when sending TS file

[Samuel Hurst]

Hello All,


I'm currently trying to do some performance comparisons between
different streaming protocols and have hit a snag with RTP. I have the
following simple sending pipeline:

filesrc location=test.ts ! tsparse set-timestamps=true ! rtpmp2tpay !
rtpsink address=...

The tsparse is important, as I'm using the logging output from this to
calculate an equivalent of glass-to-glass latency at the receiving end.

However, I discovered that I was getting a lot of discontinuity warnings
and decoder errors at the receiver, which after looking at all the RTP
timestamps coming out of tsparse and matching them with timestamps being
processed by rtpmp2tpay, there's a lot missing.

I've tried adding a queue between the elements and that doesn't help.
Does anyone else have any other ideas?


Best Regards,
Sam



_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Samuel Hurst]

On 01/09/2020 11:46, Samuel Hurst wrote:

> I'm currently trying to do some performance comparisons between
> different streaming protocols and have hit a snag with RTP. I have the
> following simple sending pipeline:
>
> filesrc location=test.ts ! tsparse set-timestamps=true ! rtpmp2tpay !
> rtpsink address=...
>
> The tsparse is important, as I'm using the logging output from this to
> calculate an equivalent of glass-to-glass latency at the receiving end.
>
> However, I discovered that I was getting a lot of discontinuity warnings
> and decoder errors at the receiver, which after looking at all the RTP
> timestamps coming out of tsparse and matching them with timestamps being
> processed by rtpmp2tpay, there's a lot missing.
>
> I've tried adding a queue between the elements and that doesn't help.
> Does anyone else have any other ideas?

Apologies, I just realised that I didn't specify my environment. I'm
running 1.17.90 (1.18 rc1) across several Linux hosts, all with
variations on the same behaviour. It appears that lower powered hosts
show the problem more readily than faster hosts.

I'm also fairly certain that it's loss within the sender and not on the
network, as I have already verified that there is no discontinuity in
RTP packet numbers on my test network, verified that there's plenty of
bandwidth with no loss across several tests using iperf, and I've also
tested it with localhost.


Best Regards,
Sam


_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel