Hello,
I'm looking into low latency real-time streaming of MJPEG videos over the network with GStreamer. I wonder what module does the frame synchronisation on the receivers side and how. On the sender I start: # gst-launch-1.0 filesrc location=output.avi ! avidemux name=demux demux.video_0 ! vaapipostproc ! vaapijpegenc quality=50 ! rtpjpegpay ! udpsink host=192.168.178.52 port=50004 and on the receiver: # gst-launch-1.0 udpsrc port=50004 ! application/x-rtp,encoding-name=JPEG,payload=26 ! queue ! rtpjpegdepay ! vaapijpegdec ! vaapipostproc ! vaapisink I have some basic questions: - Are the frames displayed as they arrive (in "udpsrc")? - Are the timestamps of the RTP packets used to display the frames at the right time? If I add "sync=false" to the sender's command, the video is displayed faster, even if I replace "queue" with "rtpjitterbuffer" in the receiver's command. Also, with high quality decoding (90%), the video starts jerking. If I play the AVI file directly on the receiver side, it looks good. What am I missing? TIA, Wolfgang. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le jeudi 04 octobre 2018 à 11:09 +0200, Wolfgang Grandegger a écrit :
> Hello, > > I'm looking into low latency real-time streaming of MJPEG videos over > the network with GStreamer. I wonder what module does the frame > synchronisation on the receivers side and how. On the sender I start: > > # gst-launch-1.0 filesrc location=output.avi ! avidemux name=demux > demux.video_0 ! vaapipostproc ! vaapijpegenc quality=50 ! rtpjpegpay > ! > udpsink host=192.168.178.52 port=50004 > > and on the receiver: > > # gst-launch-1.0 udpsrc port=50004 ! > application/x-rtp,encoding-name=JPEG,payload=26 ! queue ! > rtpjpegdepay ! > vaapijpegdec ! vaapipostproc ! vaapisink jitterbuffer to handle the time, ideally with do-timestamp=1 on the udpsrc element. > > I have some basic questions: > > - Are the frames displayed as they arrive (in "udpsrc")? It will depends on the jitterbuffer "mode" property. By default it will try to slave to the remote clock. This mode is not extremely accurate though. > > - Are the timestamps of the RTP packets used to display the > frames at the right time? Yes, if you use a jitterbuffer. > > If I add "sync=false" to the sender's command, the video is displayed > faster, even if I replace "queue" with "rtpjitterbuffer" in the > receiver's command. > > Also, with high quality decoding (90%), the video starts jerking. If > I > play the AVI file directly on the receiver side, it looks good. JPEG are big, you'll have to increase the kernel UDP buffer. sysctl net.core.rmem_max=value And then use buffer-size property on udpsrc. > > What am I missing? > > TIA, > > Wolfgang. > > > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (201 bytes) Download Attachment |
Hello,
Am 04.10.2018 um 17:44 schrieb Nicolas Dufresne: > Le jeudi 04 octobre 2018 à 11:09 +0200, Wolfgang Grandegger a écrit : >> Hello, >> >> I'm looking into low latency real-time streaming of MJPEG videos over >> the network with GStreamer. I wonder what module does the frame >> synchronisation on the receivers side and how. On the sender I start: >> >> # gst-launch-1.0 filesrc location=output.avi ! avidemux name=demux >> demux.video_0 ! vaapipostproc ! vaapijpegenc quality=50 ! rtpjpegpay >> ! >> udpsink host=192.168.178.52 port=50004 >> >> and on the receiver: >> >> # gst-launch-1.0 udpsrc port=50004 ! >> application/x-rtp,encoding-name=JPEG,payload=26 ! queue ! >> rtpjpegdepay ! >> vaapijpegdec ! vaapipostproc ! vaapisink > > To you first question, none in your pipeline. You'll need a > jitterbuffer to handle the time, ideally with do-timestamp=1 on the > udpsrc element. > >> >> I have some basic questions: >> >> - Are the frames displayed as they arrive (in "udpsrc")? > > It will depends on the jitterbuffer "mode" property. By default it will > try to slave to the remote clock. This mode is not extremely accurate > though. synchronizing clocks of the participating systems is important. Are there documents around highlighting that topic? >> >> - Are the timestamps of the RTP packets used to display the >> frames at the right time? > > Yes, if you use a jitterbuffer. > >> >> If I add "sync=false" to the sender's command, the video is displayed >> faster, even if I replace "queue" with "rtpjitterbuffer" in the >> receiver's command. >> >> Also, with high quality decoding (90%), the video starts jerking. If >> I >> play the AVI file directly on the receiver side, it looks good. > > JPEG are big, you'll have to increase the kernel UDP buffer. > > sysctl net.core.rmem_max=value > And then use buffer-size property on udpsrc. I was already aware of that option. Thanks, Wolfgang. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (853 bytes) Download Attachment |
Hello,
Am 05.10.2018 um 10:53 schrieb Wolfgang Grandegger: > Hello, > > Am 04.10.2018 um 17:44 schrieb Nicolas Dufresne: >> Le jeudi 04 octobre 2018 à 11:09 +0200, Wolfgang Grandegger a écrit : >>> Hello, >>> >>> I'm looking into low latency real-time streaming of MJPEG videos over >>> the network with GStreamer. I wonder what module does the frame >>> synchronisation on the receivers side and how. On the sender I start: >>> >>> # gst-launch-1.0 filesrc location=output.avi ! avidemux name=demux >>> demux.video_0 ! vaapipostproc ! vaapijpegenc quality=50 ! rtpjpegpay >>> ! >>> udpsink host=192.168.178.52 port=50004 >>> >>> and on the receiver: >>> >>> # gst-launch-1.0 udpsrc port=50004 ! >>> application/x-rtp,encoding-name=JPEG,payload=26 ! queue ! >>> rtpjpegdepay ! >>> vaapijpegdec ! vaapipostproc ! vaapisink >> >> To you first question, none in your pipeline. You'll need a >> jitterbuffer to handle the time, ideally with do-timestamp=1 on the >> udpsrc element. >> >>> >>> I have some basic questions: >>> >>> - Are the frames displayed as they arrive (in "udpsrc")? >> >> It will depends on the jitterbuffer "mode" property. By default it will >> try to slave to the remote clock. This mode is not extremely accurate >> though. > > I see, I will have a closer look into the various modes. Then also > synchronizing clocks of the participating systems is important. Are > there documents around highlighting that topic? https://fossies.org/linux/gst-plugins-good/gst/rtp/README Wolfgang. _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel signature.asc (853 bytes) Download Attachment |
Free forum by Nabble | Edit this page |