Maximum number of 4 RTSP feeds?

[adielfernandez]

When trying to initialize multiple pipelines, there seems to be a limit of 4 that an be opened successfully.

Custom Pipeline used:

gst.setPipeline("rtspsrc location=rtsp://admin:admin@" + IP + ":554/cam/realmonitor?channel=1&subtype=1 latency=0 ! queue2 max-size-buffers=2 ! decodebin ! videoconvert", OF_PIXELS_MONO, true, feedWidth, feedHeight);
gst.startPipeline();
gst.play();

Error thrown after the 5th camera pipeline is opened:

Setting up: Cam06
[notice ] ofGstUtils: setPipelineWithSink(): gstreamer pipeline: rtspsrc location=rtsp://admin:admin@192.168.187.38:554/cam/realmonitor?channel=1&subtype=1 latency=0 ! queue2 max-size-buffers=2 ! decodebin ! videoconvert ! appsink name=ofappsink enable-last-sample=0 caps="video/x-raw, format=GRAY8, width=640, height=512"
[verbose] ofGstUtils: startPipeline(): attaching callbacks
[verbose] P[ivpelinee is live anrd does nobto need PsReE]R OoLL wfaiting GPLsAY
tUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from pipeline4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): async done
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from ofappsink
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from rtspsrc4
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[verbose] ofGstUtils: gstHandleMessage(): unhandled message from src
[ error ] ofGstUtils: gstHandleMessage(): embedded video playback halted for plugin, module vtdechw4  reported: GStreamer encountered a general resource error.

Is this a limit to how many pipelines can be opened on a single machine or is there another error. Still trying to get more verbose debugging printed.

[adielfernandez]

These are the outstanding errors from GST_DEBUG=3. These are errors received a 5th RTSP feed is attempted, after 4 other RTSP feeds have successfully connected and reliably receive new frames. All 5 feeds are instantiated and implemented identically.

[notice ] ofGstUtils: setPipelineWithSink(): gstreamer pipeline: rtspsrc location=rtsp://admin:admin@192.168.187.38:554/cam/realmonitor?channel=1&subtype=1 latency=0 ! queue2 max-size-buffers=2 ! decodebin ! videoconvert ! appsink name=ofappsink enable-last-sample=0 caps="video/x-raw, format=GRAY8, width=640, height=512"

0:00:00.614606000  7580 0x7ffb9389e590 FIXME                
default gstutils.c:3766:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc3:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id

0:00:00.771301000  7580 0x7ffb92a27990 FIXME           
videodecoder gstvideodecoder.c:1057:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vtdechw3> Sub-class should implement drain()
0:00:00.771508000  7580 0x7ffb92a27990 FIXME           
videodecoder gstvideodecoder.c:1057:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vtdechw3> Sub-class should implement drain()

0:00:00.824044000  7580 0x7ffb93c8d190 FIXME                
default gstutils.c:3766:gchar *gst_pad_create_stream_id_internal(GstPad *, GstElement *, const gchar *):<fakesrc4:src> Creating random stream-id, consider implementing a deterministic way of creating a stream-id

0:00:00.991274000  7580 0x7ffb92a278f0 FIXME           
videodecoder gstvideodecoder.c:1057:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vtdechw4> Sub-class should implement drain()

0:00:00.991482000  7580 0x7ffb92a278f0 FIXME           
videodecoder gstvideodecoder.c:1057:GstFlowReturn gst_video_decoder_drain_out(GstVideoDecoder *, gboolean):<vtdechw4> Sub-class should implement drain()

0:00:01.002893000  7580 0x7ffb92a278f0 WARN                  
vtdec vtdec.c:530:gst_vtdec_create_session:<vtdechw4> error: VTDecompressionSessionCreate returned -12913

[ error ] ofGstUtils: gstHandleMessage(): embedded video playback halted for plugin, module vtdechw4  reported: GStreamer encountered a general resource error.

0:00:01.003897000  7580 0x7ffb929e38f0 WARN                
rtspsrc gstrtspsrc.c:5931:gst_rtspsrc_try_send:<rtspsrc4> receive interrupted

0:00:01.003913000  7580 0x7ffb929e38f0 WARN                
rtspsrc gstrtspsrc.c:8053:gst_rtspsrc_pause:<rtspsrc4> PAUSE interrupted

0:00:01.004702000  7580 0x7ffb929e38f0 WARN                
rtspsrc gstrtspsrc.c:5904:gst_rtspsrc_try_send:<rtspsrc4> send interrupted

0:00:01.004717000  7580 0x7ffb929e38f0 WARN                
rtspsrc gstrtspsrc.c:7524:gst_rtspsrc_close:<rtspsrc4> TEARDOWN interrupted

Is there an internal limit to 4 feeds that ofxGStreamer can handle or does something else need to be implemented?

[arturoc]

no there's no limit on the number of feeds at least not in OF. debug level 3 is just fixme so it won't add much from 2, you really need level 4 to see what's going on.

you can also export GST_DEBUG_NO_COLOR=1 to avoid the strange characters from color output

[adielfernandez]

Thanks, the the no_color tweak helps.

I've created the simplest possible app I could that has this problem here: https://github.com/adielfernandez/AVC-Apps/tree/master/MultiFeedSimple It's just 5 feeds that connect and show on screen and show how many frames they've received. The 5th feed appears to receive 1 single frame (i.e. isFrameNew() is true at least once) before it goes dead.

I staggered the setPipeline() calls so the feeds would set up one after the other. I also added some std::cout strings (with a bunch of line breaks) to see when things are happening. The file is in that repo but it's also here for download: https://www.dropbox.com/s/zrj9d74ghkg06un/multiFeedSimpleDebug.txt?dl=0

The error " posting message: GStreamer encountered a general resource error." happens about half way through on line 2983. I've been staring at it for hours but it's hard to know what to look for O_O

[arturoc]

the problem seems to be in:

vtdec vtdec.c:530:gst_vtdec_create_session: error: VTDecompressionSessionCreate returned -12913

vtdec seems to be an apple only plugin to decode, in this case h264, using apple apis but it seems to be failing. it's in the bad series so it's usually consider unstable.

i would try installing other plugins for decoding from http://gstreamer.freedesktop.org/data/pkg/osx/1.7.1/gstreamer-1.0-1.7.1-x86_64-packages.dmg the specific package i think it's called x264 something. once it's installed gstreamer will probably choose it before vtdec but not sure.

be aware that this plugin is GPL so if you plan to distribute this software you might need to license it as GPL too

[adielfernandez]

I was hopeful but no luck. Installing other plugins from the packages.dmg doesn't make it any better. Even after erasing everything and starting with a fresh GStreamer install :(

However, I've found out a bit more info after digging around. There seems to be an issue with decoding x264 with AppleMedia decoders using any OSX later than 10.9. It's a bit over my head but it's something to do with hardware acceleration being enabled. It pops enough to make me think it's related. Two links among others.

GStreamer reference to vtdec hardware acceleration on 10.9: https://lists.freedesktop.org/archives/gstreamer-commits/2013-December/075997.html

Bug report from non-gstreamer source citing crash inside "VTDecompressionSessionCreate" when multiple decoders are initialized in quick succession: https://bugzilla.mozilla.org/show_bug.cgi?id=1062596

BUT... I found a workaround for my case in particular. I figured I'd see if there were similar issues decoding MJPEG streams since my cameras can export that as well, so I reconfigued the pipeline and it works great!

In case anyone else needs it: gst.setPipeline("rtspsrc location=rtsp://admin:admin@" + IP + ":554/cam/realmonitor?channel=1&subtype=1 latency=0 ! rtpjpegdepay ! jpegdec ! queue ! decodebin ! videoconvert", OF_PIXELS_MONO, true, feedWidth, feedHeight);

The latency actually seems even better than with H264 but that might just be me imagining it after wrestling with this for so many days, haha.

Not sure if you want to close this issue or relabel it as an OSX bug beyond the scope of the addon(?). Anyways, thanks a ton for the help!