RTP payloaders and streaming over UDP/TCP

[Wim Taymans]

It is a limitation of the current payloader. the problem is that the
depayloader can't handle packets bigger than 0xffff currently and so the
payloader refuses to make them. If you fix the depayloader, you can simply
remove that check in the payloader.


On 21 November 2013 10:22, distran <distran.sensors at gmail.com> wrote:

> Yep, I tried it, and with no effect. It seems that for certain frames that
> are big enough rtptheorapay cannot handle them. What it seems is that
> rtptheorapay expects frames that can fit into one packet and does not map
> larger frames into multiple packets automatically (although according to
> RTP
> Theora specification from RFC it should).
>
> Let me show you an example comparing rtptheorapay and rtpjpegpay.
>
> export GST_DEBUG=2
>
> RTPJPEGPAY
>
> Receiving end:
> gst-launch-0.10 udpsrc port=5000 caps="application/x-rtp,
> media=(string)video, clock-rate=(int)90000, encoding-name=(string)JPEG" !
> rtpjpegdepay ! jpegdec ! ffmpegcolorspace ! videoscale ! ximagesink
>
> Sending end:
> 1. Random images, small (360x240), send with payloader:
> gst-launch-0.10 -v videotestsrc horizontal-speed=3 is-live=true
> pattern=snow
> ! timeoverlay ! ffmpegcolorspace !
> video/x-raw-yuv,width=360,height=240,framerate=\(fraction\)30/1 !
> ffmpegcolorspace ! jpegenc ! rtpjpegpay ! udpsink host=127.0.0.1 port=5000
>
> 2. Random images, big (640x480), send with payloader:
> gst-launch-0.10 -v videotestsrc horizontal-speed=3 is-live=true
> pattern=snow
> ! timeoverlay ! ffmpegcolorspace !
> video/x-raw-yuv,width=640,height=480,framerate=\(fraction\)30/1 !
> ffmpegcolorspace ! jpegenc ! rtpjpegpay ! udpsink host=127.0.0.1 port=5000
>
> In both cases - it works.
>
> RTPTHEORAPAY
> Receiving end (start it first so that config is exchanged):
> gst-launch-0.10 udpsrc port=5000 caps="application/x-rtp,
> media=(string)video, clock-rate=(int)90000, encoding-name=(string)THEORA" !
> rtptheoradepay ! theoradec ! ffmpegcolorspace ! videoscale ! ximagesink
>
> Sending end:
> 1. Random images, small (360x240), send with payloader:
>  gst-launch-0.10 -v videotestsrc horizontal-speed=3 is-live=true
> pattern=snow ! timeoverlay ! ffmpegcolorspace !
> video/x-raw-yuv,width=360,height=240,framerate=\(fraction\)30/1 !
> ffmpegcolorspace ! theoraenc ! rtptheorapay config-interval=100 ! udpsink
> host=127.0.0.1 port=5000
>
> 2. Random images, big (640x480), send with payloader:
> gst-launch-0.10 -v videotestsrc horizontal-speed=3 is-live=true
> pattern=snow
> ! timeoverlay ! ffmpegcolorspace !
> video/x-raw-yuv,width=640,height=480,framerate=\(fraction\)30/1 !
> ffmpegcolorspace ! theoraenc ! rtptheorapay config-interval=100 ! udpsink
> host=127.0.0.1 port=5000
>
> In the second case nothing gets send - rtptheorapay complaing about too big
> size of the packet it received or computed.
>
>
>
> These sizes are probably sizes of compressed frames, since similar sizes I
> am getting when trying to send jpeg images without rtpjpegpay (so that each
> one is directly fitted into UDP payload.
>
> (the same as above, but without rtpjpegpay)
> gst-launch-0.10 -v videotestsrc horizontal-speed=3 is-live=true
> pattern=snow
> ! timeoverlay ! ffmpegcolorspace !
> video/x-raw-yuv,width=640,height=480,framerate=\(fraction\)30/1 !
> ffmpegcolorspace ! jpegenc ! udpsink host=127.0.0.1 port=5000
>
>
>
> In both cases we have a frame that is around 198000 bytes. What I find
> strange is that rtptheorapay cannot deal with such big frames, while
> rtpjpegpay (and other payloaders) seem to deal with the issue naturally.
>
> What can be the problem and do anyone knows of some workarounds? Is your
> installation of GStreamer reproducing the same behaviour?
>
> Thanks for all your help!
>
> Regards,
> Michal
>
>
>
>
>
>
>
> --
> View this message in context:
> http://gstreamer-devel.966125.n4.nabble.com/RTP-payloaders-and-streaming-over-UDP-TCP-tp4663441p4663450.html
> Sent from the GStreamer-devel mailing list archive at Nabble.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/20131121/c1234130/attachment-0001.html>