GNOME Bugzilla – Bug 580880
gstrtpjpegpay is not functioning properly; rtp jpeg payload is corrupted
Last modified: 2009-05-05 14:37:58 UTC
Please describe the problem: when using a MJPEG camera (http source), Axis 243SA mjpeg; I re-multicast it with: $ gst-launch souphttpsrc location="http://10.3.0.71/axis-cgi//mjpg/video.cgi" typefind=true ! multipartdemux ! udpsink host=226.226.226.220 port=2277 This step is basically removing the http unicast and multicasting for easy usage. Inspecting the stream with $ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! jpegdec ! autovideosink shows a clean stream of video. The next step is to send the stream (UDP) and package it in RTP: $ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! jpegdec ! jpegenc ! rtpjpegpay ! udpsink host=226.226.226.120 port=2277 the jpegdec followed by the jpegenc is mainly due to a missing jpegparse as discussed on IRC. Reading the re-encoded JPEG stream with $ gst-launch udpsrc multicast-group=226.226.226.120 port=2277 caps="application/x-rtp,clock-rate=(int)90000" ! rtpjpegdepay ! jpegdec ! autovideosink is fine again. However, when re-sending the JPEG stream without re-encoding: jpegbinrtp is a bin that uses a jpeg dec/enc trick to get the resolution needed for rtpjpegpay $ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 ! rtpjpegpay silent=false ! udpsink host=226.226.226.120 port=2277Setting pipeline to PAUSED ... Setup Streaming. No decoding. Setup streaming. Pipeline is live and does not need PREROLL ... Setting pipeline to PLAYING ... New clock: GstSystemClock Found caps "image/jpeg". Unhandled stream type, ghosting pad. Ghosting pad is not linked: <recv_video_00>. Ghosting pad is a src: <recv_video_00>. Ghosting pad is not linked: <recvp_video_00>. Ghosting pad is a src: <recvp_video_00>. New barcorecvp pad, name: <recvp_video_00>. Setup streaming. No decoding/save. Setup streaming. Found caps "image/jpeg". JPEG Elementary Stream. TS wrapping is not yet implemented for this type of stream. The width/height caps are missing, reencoding. Found caps "image/jpeg, width=(int)704, height=(int)576, framerate=(fraction)0/1". JPEG Elementary Stream. TS wrapping is not yet implemented for this type of stream. The width/height caps are present, ghosting. Pad was detected with enc/dec loop. Stream blocked. Ghosting pad is not linked: <send_src_00>. Ghosting pad is a src: <send_src_00>. Ghosting pad is not linked: <sendp_src_00>. Ghosting pad is a src: <sendp_src_00>. New barcosendp pad, name: <sendp_src_00>. <sendp_src_00> is a src pad, ghosting. Ghosting pad is not linked: <mgs_src_00>. Ghosting pad is a src: <mgs_src_00>. Stream unblocked. WARNING: from element /GstPipeline:pipeline0/GstUDPSink:udpsink0: Internal data flow problem. Additional debug info: gstbasesink.c(2867): gst_base_sink_chain_unlocked (): /GstPipeline:pipeline0/GstUDPSink:udpsink0: Received buffer without a new-segment. Assuming timestamps start from 0. And re-subscribing to the stream; as described before, the image is completely scrambled. Steps to reproduce: cf. supra Actual results: corrupted image Expected results: good image Does this happen every time? yes Other information: should have taken the normal bugzilla form.
The rtpjpegbin can be be skipped with manually determining the res and starting the chain as follows: $ gst-launch udpsrc multicast-group=226.226.226.220 port=2277 caps="image/jpeg, width=(int)704, height=(int)576" ! rtpjpegpay ! udpsink host=226.226.226.120 port=2277 This is easier to reproduce. I can make a gdp dump available for reproduction if needed.
Please make a gdp log like this: gst-launch udpsrc multicast-group=226.226.226.220 port=2277 caps="image/jpeg, width=(int)704, height=(int)576" ! gdppay ! filesink location=gdp.log Then gzip and attach the resulting gdp.log.
Setup GDP: 1. gst-launch souphttpsrc location="http://10.3.0.71/axis-cgi//mjpg/video.cgi" typefind=true ! multipartdemux ! udpsink host=226.226.226.220 port=2277 2. gst-launch udpsrc multicast-group=226.226.226.220 port=2277 caps="image/jpeg,width=(int)704, height=(int)576" ! rtpjpegpay ! udpsink host=226.226.226.120 port=2277 3. gst-launch udpsrc multicast-group=226.226.226.120 port=2277 caps="application/x-rtp,clock-rate=(int)90000" ! rtpjpegdepay ! jpegdec ! autovideosink -> warnings: WARNING: from element /GstPipeline:pipeline0/GstRtpJPEGDepay:rtpjpegdepay0: Empty Payload. Additional debug info: gstrtpjpegdepay.c(596): gst_rtp_jpeg_depay_process (): /GstPipeline:pipeline0/GstRtpJPEGDepay:rtpjpegdepay0 4. gst-launch udpsrc multicast-group=226.226.226.220 port=2277 caps="image/jpeg,width=(int)704, height=(int)576" ! gdppay ! filesink location=gdp.log
gdp log on: http://crichton.homelinux.org/~marc/gdp-mjpeg-rtp.log.gz about 20" of MJPEG video
You need to manually set the type to 0 on the payloader. I'm going to make it detect the type from the SOF header instead.
commit 0f1033c59f0e8c4ab637b29194ffdc0c03a81309 Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Tue May 5 16:32:17 2009 +0200 rtpjpegpay: correctly set the type header Don't require width/height on the caps. Use the SOF header to find width/height and fall back to the caps if there is no SOF. Also use the SOF info to find the subsampling and quantization tables used. This allows us to set the right type value in the JPEG rtp header. Deprecate the quality property, it's unused now and it was used wrongly before. Always send full quant tables for now until we have some code to detect default ones. Fixes #580880