RTSP Not working on Dahua IP Cams

jayeazy's picture

Submitted by on

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

1.RTSP Stream doesn't work with DAHUA Web cam.

Have you found a workaround?: 

No

Other notes: 

VLC Does seem to play the same RTSP stream.... properly.... ERROR from debug:

# pid=9345  t= 99,1211s              VuoCompiler.cc:2094            getDependenciesForComposition()     Gathering dependencies for '/tmp/Dahua Test-CNt3OF.bc'…
# pid=9345  t= 99,1288s              VuoCompiler.cc:2158            getDependenciesForComposition()     Done.
# pid=9345  t= 99,1342s              VuoCompiler.cc:2755                                     link()     Linking '/tmp/Dahua Test-CNt3OF-resource0.dylib'…
# pid=9345  t= 99,3551s              VuoCompiler.cc:2910                                     link()     Done.
# pid=9345  t= 99,3561s              VuoCompiler.cc:2755                                     link()     Linking '/tmp/Dahua Test-CNt3OF.dylib'…
# pid=9345  t= 99,5993s              VuoCompiler.cc:2910                                     link()     Done.
# pid=9345  t= 99,6073s                VuoRunner.cc:1092                       replaceComposition()     Loading composition…
# pid=9345  t= 99,8742s                VuoRunner.cc:1137                       replaceComposition()         Done.
# pid=9667  t=  0.1439s             VuoGlContext.cc:50                     VuoGlContext_renderers()     Renderer 0: Intel HD 5000 (Iris)
# pid=9667  t=  0.1736s             VuoGlContext.cc:54                     VuoGlContext_renderers()         Online             : yes
# pid=9667  t=  0.1737s             VuoGlContext.cc:58                     VuoGlContext_renderers()         Accelerated        : yes
# pid=9667  t=  0.1738s             VuoGlContext.cc:63                     VuoGlContext_renderers()         Video memory       : 1536 MB
# pid=9667  t=  0.1738s             VuoGlContext.cc:68                     VuoGlContext_renderers()         Texture memory     : 1536 MB
# pid=9667  t=  0.1739s             VuoGlContext.cc:73                     VuoGlContext_renderers()         Display mask       : 0x1f
# pid=9667  t=  0.1741s             VuoGlContext.cc:77                     VuoGlContext_renderers()                              Apple Computer Inc: Color LCD (2012-W48)
# pid=9667  t=  0.1742s             VuoGlContext.cc:82                     VuoGlContext_renderers()         OpenGL version     : 4
# pid=9667  t=  0.1855s             VuoGlContext.cc:95                     VuoGlContext_renderers()         OpenGL 2           : Intel Iris Pro OpenGL Engine (2.1 INTEL-10.6.33) maxTextureSize=16384
# pid=9667  t=  0.1905s             VuoGlContext.cc:113                    VuoGlContext_renderers()         OpenGL Core Profile: Intel Iris Pro OpenGL Engine (4.1 INTEL-10.6.33) maxTextureSize=16384
# pid=9667  t=  0.1935s             VuoGlContext.cc:122                    VuoGlContext_renderers()         OpenCL supported   : yes
# pid=9667  t=  0.1937s             VuoGlContext.cc:50                     VuoGlContext_renderers()     Renderer 1: Apple Software Renderer (GenericFloat)
# pid=9667  t=  0.1939s             VuoGlContext.cc:54                     VuoGlContext_renderers()         Online             : yes
# pid=9667  t=  0.1940s             VuoGlContext.cc:58                     VuoGlContext_renderers()         Accelerated        : no
# pid=9667  t=  0.1941s             VuoGlContext.cc:73                     VuoGlContext_renderers()         Display mask       : 0x1f
# pid=9667  t=  0.1942s             VuoGlContext.cc:77                     VuoGlContext_renderers()                              Apple Computer Inc: Color LCD (2012-W48)
# pid=9667  t=  0.1943s             VuoGlContext.cc:82                     VuoGlContext_renderers()         OpenGL version     : 4
# pid=9667  t=  0.1972s             VuoGlContext.cc:95                     VuoGlContext_renderers()         OpenGL 2           : Intel Iris Pro OpenGL Engine (2.1 INTEL-10.6.33) maxTextureSize=16384
# pid=9667  t=  0.2024s             VuoGlContext.cc:113                    VuoGlContext_renderers()         OpenGL Core Profile: Intel Iris Pro OpenGL Engine (4.1 INTEL-10.6.33) maxTextureSize=16384
# pid=9667  t=  0.2050s             VuoGlContext.cc:122                    VuoGlContext_renderers()         OpenCL supported   : no
# pid=9667  t=  0.2052s             VuoGlContext.cc:139                    VuoGlContext_renderers()     Driver: AppleIntelHD5000Graphics
# pid=9667  t=  0.2106s             VuoGlContext.cc:352                             createContext()     Created OpenGL context 0x7fb23a089c00 on Intel HD 5000 (Iris)
# pid=9667  t=  0.2317s           VuoGraphicsView.m:439                -[VuoGraphicsView drawRect:]     OpenGL context 0x7fb238859400's virtual screen changed to 0
# pid=9667  t=  0.2857s                 VuoAudio.cc:499                     VuoAudioOut_getShared()     Using default device #2, name "Apple Inc.: Built-in Output".
[20:15:37.368] FigByteFlumeCustomURLOpen signalled err=-12936 (kFigByteFlumeError_BadState) (no provider) at /SourceCache/CoreMedia/CoreMedia-1562.240/Prototypes/FigHTTP/FigByteFlumeCustomURL.c line 1486
# pid=9667  t=  0.2926s         VuoAvPlayerObject.m:297                -[VuoAvPlayerObject setURL:]     AvFoundation cannot play this asset (isPlayable=0, hasProtectedContent=0, isReadable=0).
[rtsp @ 0x7fb23c000000] SDP:
v=0
o=- 2251938844 2251938844 IN IP4 0.0.0.0
s=Media Server
c=IN IP4 0.0.0.0
t=0 0
a=control:*
a=packetization-supported:DH
a=rtppayload-supported:DH
a=range:npt=now-
m=video 0 RTP/AVP 96
a=control:trackID=0
a=framerate:25.000000
a=rtpmap:96 H264/90000
a=fmtp:96 packetization-mode=1;profile-level-id=4D0029;sprop-parameter-sets=Z00AKZpkA8ARPy4C3AQEBQAAAwPoAADDUOhgAEEeAABBHgu8uNDAAII8AACCPBd5cKAA,aO48gAA=
a=recvonly

# pid=9667  t=  0.5394s         VuoFfmpegDecoder.cc:125                                Initialize()     FFmpeg context flags: 0x0
# pid=9667  t=  0.5395s         VuoFfmpegDecoder.cc:131                                Initialize()     FFmpeg input format : 'RTSP input' (rtsp)  flags=0x1  codec=0x0
# pid=9667  t=  1.7724s         VuoFfmpegDecoder.cc:188                           InitializeVideo()     FFmpeg video codec  : 'H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10' (h264)
[swscaler @ 0x7fb23b13e200] deprecated pixel format used, make sure you did set range correctly
# pid=9667  t=  1.8298s                VuoGlPool.cc:319   VuoGlTexture_getMaximumTextureBytes_block()   1305 MB
[rtsp @ 0x7fb23c000000] method PAUSE failed: 455 Method Not Valid in This State
[h264 @ 0x7fb23883bc00] Missing reference picture, default is 0
[h264 @ 0x7fb23883bc00] decode_slice_header error
[swscaler @ 0x7fb238af4c00] deprecated pixel format used, make sure you did set range correctly
[swscaler @ 0x7fb239348a00] deprecated pixel format used, make sure you did set range correctly
[rtsp @ 0x7fb23c000000] method PAUSE failed: 455 Method Not Valid in This State
[h264 @ 0x7fb23883bc00] Missing reference picture, default is 0
[h264 @ 0x7fb23883bc00] decode_slice_header error
# pid=9667  t=  7.0600s           VuoVideoPlayer.cc:74                                     Create()     Using FFmpeg video decoder despite optimization preference.
# pid=9667  t=  7.0611s         VuoDisplayRefresh.c:125          VuoDisplayRefresh_enableTriggers()     Refresh: 59.9903 Hz (337750000/5630080)
# pid=9667  t=  7.0612s         VuoDisplayRefresh.c:134          VuoDisplayRefresh_enableTriggers()     Latency: unknown
# pid=9345  t=107,8879s                VuoRunner.cc:2709                   stopBecauseLostContact()     The connection between the composition ('VuoCompositionLoader') and runner timed out while listening for telemetry.

Feedback Loop signal in a diffeent part of the composition

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

  1. open the attached vuo program
  2. connect "reached target" output pin of "1. Smooth with duration" node (bottom left of the composition) to "Increment" pin of "2. stato" node
  3. You have a feedback signal, in a different part of the composition, non involved by this cable

Have you found a workaround?: 

no

Compositions: 

AttachmentSize
Binary Data palodelcolle.vuo48.31 KB

3D Object Transparency / VDMX

Status: 

Vuo version: 

Fixed in Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●●○ — It prevents me from completing a specific task with Vuo.

Steps causing the bug to occur: 

  1. build image generator scene using multiple 3d Objects. Add a shader with some transparency. Combine those objects and render to image for use in other applications
  2. transparency of all shaders is missing.

Have you found a workaround?: 

Need to render each object to an image then use blend images to composite scene.

Other notes: 

In previous versions of Vuo. I've always combined the scenes using the Combine 3D Objects node. Something about this node feels like it's been changed.

Screenshots: 

Compositions: 

AttachmentSize
Binary Data Blight3.vuo12.15 KB
Binary Data Blight4.vuo14.85 KB

OSC parames shuffled

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●○○ — It's annoying but I can work around it.

Steps causing the bug to occur: 

  1. open the patch
  2. send a OSC with 7 parameters to port 57111
  3. receive OSC with a server listening at 57112
  4. It should receive the same osc, instead parameters are shuffled

Have you found a workaround?: 

no

Screenshots: 

Compositions: 

AttachmentSize
Binary Data console||QLab->QC Voting System.vuo8 KB

Build List not behaving as expected when Building from another list of elements (same issue for Process List)

Status: 

Vuo version: 

OS version: 

  • Mac OS 10.10

How severely does this bug affect you?: 

●●●● — It prevents me from using Vuo at all.

Steps causing the bug to occur: 

  1. Make a simple loop to generate a list of integers [1,10] or 2D points [(1,1),(10,10)]
  2. Make a new loop to perform a simple calculation on the elements in the first list using the Get Item from List node.
  3. Make sure the second loop only has the one firing event from the first Build List node.
  4. Note the first two elements in the second list are repeated and the then the rest of the elements are not in correct place in list. 3rd element is what should be in 2nd element, 9th is what should be in 10th place. (See initial output of demo composition in illustration below)

Figure 1

  1. Now manually fire an event using the Vuo Editor either at the inputs or the output of the first Build List node (see pink arrows in Fig. 1). Now we have an even stranger output from the second Build List node, note what should be element 10 is now in the place of element 1 (Fig. 2 yellow arrow) and the rest of elements are out of place by one element (3 in 2nd place etc see Fig. 2 orange arrow):

  1. Now fire an event at using the Vuo Editor on the Fire input port of the second Build List node. (Fig. 1 "2" with green arrow) and the second Build List node output is correct. Omitting step 5 and going from step 4 to step 6 will produce the same correct result.

  1. This kind of element order and duplication anomaly happens using the Process List node also.

  2. Using a Hold List node for the first list and using various fire events to the refresh port doesn't seem make a jot of difference to this sequence of documented misbehaviors.

Have you found a workaround?: 

Unroll a loop and manually wire every single instance with copy and paste. Majorly time consuming for moderately sized lists, impossible for larger lists.

Other notes: 

This kind of unexpected behavior, and a lack of explanation in the Manual if it's a "feature", makes me extremely reluctant to rely on Vuo for real work ATM.

I've had to unroll loops and manually wire 25 instants of a series of nodes just to work around this issue. For longer lists this isn't even an option and given how slow Vuo gets with 100+ nodes on the editor and how hard it is to turn functioning nodes into an identical Sub-composition that just works (like making a QC macro just works) the node count rises quickly avoiding making loops.

Building and processing my own lists of various datatypes using fast C backed patches/nodes was the reason I first proposed a QC replacement. QC with JS just wasn't performant generating and manipulating large amounts of QC structured data … so when hearing about VUO was very excited to say the least (and supportive!).

But this fundamental task for me is not working — even so far into the Vuo development as 1.2.6 — this is frustrating.

There's not even a way to simply fire a "double event" to work around this problem that I can find. Certainly Spin Off Event(s) isn't doing it for me. The entire event paradigm while very powerful compared with QC's uniform pull paradigm is quite hard to debug and extremely hard to control at my stage of Vuo understanding. I think it needs work. Stepping through compositions frame by frame (and highlighting the event chain somehow in Editor) would be a start to easier debugging perhaps, but I feel like there needs to be a more user friendly abstraction over the top of it all for novice and intermediate users, I can't think how though yet. I tried dozens of permutations of event cables on this composition to force a second fire event on the second Build List node (without going to extreme of setting up a timer and firing again after 0.1 seconds or something). I feel like a "Make Double Event" node is required just to workaround this problem I keep colliding with in my experiments with Vuo, but how to even do it, wait for the next redraw from the screen? I'm not even using a render node in this. :-)

Pages

Subscribe to RSS - Mac OS 10.10