<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">I've made some good progress.</div><div dir="ltr"><br><div>Apparently GStreamer RTSP server needed the RTP payload to be named "pay0".</div><div>The "rtpjpegpay" element defaulted to a name of "rtpjpegpay0".<br></div><div>I've also set the payload type to 26 ("pt=26") as I think it should be.</div><div><br></div><div>I then needed to insert a capsfilter of "image/jpeg,width=640,height=480" after the "multipartdemux" element.</div><div>This got me an initial image and an endless stream of "FIXME" messages (at GST_DEBUG="*:3") but video wasn't animated....</div><div><br></div><div>The final fix was to use the "do-timestamp=true" and "is_live=true" parameters with the "souphttpsrc" element.</div><div>I now have a nicely restreamed feed but I still get an endless stream of FIXME and some WARNs (at GST_DEBUG="*:3").</div><div>I guess the answer to that is not to look at the debug messages!</div><div><br></div><div>My final pipeline is:</div><div>"souphttpsrc location=<a href="http://10.10.1.1:8196/">http://10.10.1.1:8196/</a> do-timestamp=true is_live=true ! multipartdemux ! image/jpeg,width=640,height=480 ! rtpjpegpay name=pay0 pt=26"<br></div><div><br></div><div>Does anyone know if I can improve on this?<br></div><div><br></div><div>The FIXME and WARNs are:</div><div><br></div><div><div>1 of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0xff</div><div>Many of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0x00</div><div>2 of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0xff</div><div>1 of:</div><div>WARN              rtpjpegpay gstrtpjpegpay.c:733:gst_rtp_jpeg_pay_handle_buffer:<pay0> EOI reached before SOS!</div><div>2 of:</div><div>WARN              rtspstream rtsp-stream.c:4504:gst_rtsp_stream_seekable:<GstRTSPStream@0x7f9198048330> seeking query failed</div><div>2 of:</div><div>FIXME              rtspmedia rtsp-media.c:3833:gst_rtsp_media_suspend: suspend for dynamic pipelines needs fixing</div><div>1 of:</div><div>FIXME             rtspclient rtsp-client.c:1646:handle_play_request:<GstRTSPClient@0x1417120> Add support for seek style (null)</div><div>3 of:</div><div>WARN              rtspstream rtsp-stream.c:4504:gst_rtsp_stream_seekable:<GstRTSPStream@0x7f9198048330> seeking query failed</div><div>1 of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0xff</div><div>Many of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0x00</div><div>1 of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0xff</div><div>1 of:</div><div>WARN              rtpjpegpay gstrtpjpegpay.c:733:gst_rtp_jpeg_pay_handle_buffer:<pay0> EOI reached before SOS!</div><div>1 of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0xff</div><div>Many of:</div><div>FIXME             rtpjpegpay gstrtpjpegpay.c:751:gst_rtp_jpeg_pay_handle_buffer:<pay0> unhandled marker 0x00</div><div>etc...</div></div><div><br></div><div>Thanks in advance</div></div></div></div></div></div></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 6 Mar 2019 at 12:11, Matt Thyer <<a href="mailto:matt.thyer@gmail.com">matt.thyer@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>Dear GStreamer developers,</div><div><br></div><div>I'm trying to re-stream a Motion-JPEG stream via the GStreamer RTSP server (i.e. RFC2435 extension to RTSP) but am having trouble with my pipeline.</div><div>The video source is an "i-Spy Tank" by HappyCow. See: <a href="https://www.youtube.com/watch?v=p-_fnMRzcKE" target="_blank">https://www.youtube.com/watch?v=p-_fnMRzcKE</a></div><div>There's a blog on accessing this tank's video, turret and track controls here: <a href="https://devblog.kogan.com/blog/hacking-the-wifi-spy-tank" target="_blank">https://devblog.kogan.com/blog/hacking-the-wifi-spy-tank</a><br></div><div>Think of it as a simple WiFi connected web camera where the device presents as an open wireless access point.<br></div><div>The Motion JPEG video stream is at: <a href="http://10.10.1.1:8196/" target="_blank">http://10.10.1.1:8196/</a> (not port 9876 as the devblog confusingly says!).<br></div><div><br></div><div>VLC tells me that the stream is:</div><div>   Codec: Motion JPEG (MJPG)</div><div>   Resolution: 640x480</div><div>   Display resolution: 640x480</div><div>   Decoded format: Planar 4:2:2 YUV full scale</div><div><br></div><div>What's working:</div><div>I've successfully saved the individual JPEG frames with the following pipeline:<br></div><div>gst-launch-1.0 -e souphttpsrc location=<a href="http://10.10.1.1:8196/" target="_blank">http://10.10.1.1:8196/</a> ! multipartdemux ! image/jpeg,width=640,height=480 ! multifilesink location=frame%05d.jpeg<br></div><div><br></div><div>What's not working:</div><div>I'm unable to re-stream using GStreamer RTSP so far...<br></div><div>I've tried pipelines: "souphttpsrc location=<a href="http://10.10.1.1:8196/" target="_blank">http://10.10.1.1:8196/</a> ! multipartdemux ! rtpjpegpay"</div><div>and: "souphttpsrc location=<a href="http://10.10.1.1:8196/" target="_blank">http://10.10.1.1:8196/</a> do-timestamp=true ! multipartdemux ! image/jpeg,width=640,height=480 ! rtpjpegpay"</div><div>But both of these pipelines fail with error:<br></div><div>"FIXME              rtspmedia rtsp-media.c:3835:gst_rtsp_media_suspend: suspend for dynamic pipelines needs fixing"</div><div>(When run with GST_DEBUG="*:3").</div><div>My understanding of this error is that it's due to a capabilities mismatch between elements.</div><div>Is this the case?</div><div><br></div><div>I've seen some people use "avdec_mjpeg" and then re-encode but I'd rather not go to that extreme... If it's incompatible or missing capabilities, how can I artificially provide these caps without transcoding?</div><div><br></div><div>Matt Thyer</div></div></div>
</blockquote></div>