h.264 Video Streaming over TCP

[pfarmer]

Server and Client are on the same machine
With UDP it works.

Server:
$ gst-launch-1.0 videotestsrc horizontal-speed=5 ! x264enc
tune="zerolatency" threads=1 ! rtph264pay config-interval=2 ! udpsink
port=8554
Client:
$ gst-launch-1.0 udpsrc port=8554 ! application/x-rtp, payload=96 !
rtpjitterbuffer ! rtph264depay ! avdec_h264 ! xvimagesink

For some reason (firewall related) I have to use TCP. While replacing the
udp sink/src by tcpserversink/tcpclientsrc

Server
gst-launch-1.0 videotestsrc horizontal-speed=5 ! x264enc tune="zerolatency"
threads=1 ! rtph264pay config-interval=2 ! tcpserversink port=8554
Client:
gst-launch-1.0 tcpclientsrc port=8554 host=localhost ! application/x-rtp,
payload=96 !  rtph264depay ! avdec_h264 ! xvimagesink

1.) The rtpjitterbuffer does not work. The launch fails with "tcpclientsrc0:
streaming task paused, reason error (-5)"
       why is it so? 
2.) The stream randomly fails afer a while with "rtph264depay0: NAL unit
type 26 not supported yet" Whereas the number is different in each run.
Before hand the debug info "rtph264depay0: Could not decode stream." occurs
frequently. So it seems  So it seems the deepayloader does not get the
access delimiter correctly. May guess is that the mtu is not set correctly
for the payloader at the server side. A look in wireshark gave that some
packets have sometimes a size are above 11000Bytes. This should not be the
case since the payloader has a default mtu of 1400Bytes.
      What can i do let it decode the stream correctly?
3.) The packets are encapsulated in RTSP
      Is this a desired behavior? I thought the gst buffers (or rtp packets)
should just be put in the tcp data block.







--
View this message in context: http://gstreamer-devel.966125.n4.nabble.com/h-264-Video-Streaming-over-TCP-tp4658747.html
Sent from the GStreamer-devel mailing list archive at Nabble.com.