[gst-devel] how do I packet pace rtp network traffic?

[Marco Ballesio]

Hi,

On Thu, Jan 20, 2011 at 11:54 AM, Redfern, Keith <kredfern at tycoint.com> wrote:
> We are developing a gstreamer based pipeline to read a video source, rtp
> payload the video frame and then udpsink the rtp packets.
>
> We are finding that the pipeline bursts the rtp data unto the network,
> creating network spikes. In one example, the interpacket network delay is
> about 15micro seconds for approx 150 packets, meaning the whole video frame
> is delivered unto the network in 2.25ms.

It's conceptually right that fragmented packets, having all the same
timestamp, are sent as fast as possible over the network, the
bottleneck being the network and physical layer setting. It's usually
bad to try and artificially delay packets, as you will accrue network
latencies over the time.

If your problem is the number of packets (not the size of them) it's
good to try with an higher MTU, you can usually set it from the
payloader. If the MTU is already set appropriately (it really depends
on the network you're using) or you're actually concerned about the #
of bytes sent across the network, then you're encoding with too high
parameters / quality. Try one or more of the following:

- Reduce frame resolution.
- Reduce frame rate.
- Reduce encoder output bitrate.
- Reduce encoder output quality.
- Use a better encoder (e.g. h264 is usually better than mpeg-2).
- Increase the number of P frames between I frames (or, that is the
same, decrease the frequency of I frames).
- Already said, increase the MTU (it will reduce the overhead caused
by RTP, UDP and IP on the payload).

>
> Is there some way in which to ‘pace’ the rtp packets so that it takes
> 20-30ms to send the same frame?

Probably, but you're going through a lot of problems doing that ;) .

Regards,
Marco

>
>
>
> Keith
>
>
>
>
> ________________________________
> Tyco Safety Products/CEM Systems Ltd.
> Registered in Northern Ireland: NI 25728.  Registered Office: 195 Airport
> Road West, Belfast, BT3 9ED.
>
> Please note that any views or opinions presented in this email are solely
> those of the author and do not necessarily represent those of the company.
> This email and any attachments are confidential and intended solely for the
> use of the individual or entity to whom they are addressed. If you have
> received this email in error please notify the sender immediately and delete
> any copies in your possession.
>
>
> ------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gstreamer-devel
>
>