Streaming RTP video with MTU property set

[Chuck Crisler]

For RTP shouldn't the MTU be set on the payloader rather than the sink?
Otherwise, the payloader will generate packets with a 1400 byte MTU and
they will get fragmented later. However, often the DNF (do not fragment)
bits get set and that causes a real mess.

On Sun, Aug 16, 2015 at 3:32 AM, Sebastian Dröge <sebastian at centricular.com>
wrote:

> On So, 2015-08-16 at 10:30 +0530, Prasad Bhat wrote:
> > Hi All,
> >
> > I am writing source and sink plugins for a custom GStreamer pipline,
> > and facing an issue.
> > The medium that transports the video has a mtu limitation, So I am
> > setting mtu property in the transportsink.
> >
> > [...]
> > In the myvidsink I have a bin, which has capsfilter, rtph264pay and
> > transportsink. The mtu property is set on rtph264pay.
> >
> > [...]
> >
> > The problem I am facing is, the video streams properly for 10-15
> > seconds, and then it gets corrupted. Could anyone please help me by
> > pointing out what I am doing wrong?
>
> Check with e.g. wireshark if packets get lost, or if any packet
> fragmentation is happening. RTP packets have a sequence number, and
> that's supposed to be monotonically increasing by one.
>
>
> Also make sure that you have large enough kernel-side buffers for the
> UDP sockets on both sides, and try increasing them if you didn't do so
> yet.
>
> --
> Sebastian Dröge, Centricular Ltd · http://www.centricular.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/gstreamer-devel/attachments/20150817/a1532fda/attachment.html>