• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 99 subscribers
  • Views 1520 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

DM365-IPNC video streaming protocol

bo yu54559
Intellectual 370 points

I downloaded V2.0 IPNC SDK and built it and loaded it. It worked great. To my surprise, when I sniffed the network traffic, the video streaming doesn't use RTP/RTCP/RTSP. It is UDP with dest port 5000 (commplex-main). Is this a proprietary protocol or I misunderstood it ?

 

Thanks.

 

Bo

  • 0
    Genius 5240 points

    What is the compression (MPEG2/MPEG4/MJPEG/H264)?  When you look at the packets does the data start with a hex 47, and the packet data size a multiple of 188?  That would be transport stream.

    John A

  • 0 in reply to John Anderson
    Intellectual 370 points

    It is H264 (1280x720). The UDP payload size is 1448. So it is not a multiple of 188. I did not find 0x47 either.

    The src port of IPNC is 6970. Sometimes I can see my host computer send a packet to IPNC port 6971. It is very similar to RTP/RTCP port arrangement.

    Bo

  • 0 in reply to bo yu54559
    Genius 5240 points

    What are the first few bytes of each packet?  I've written a H264 streaming application with the DM368 that uses RTP for data and RTSP for access.  RTSP should use port 554.  Older versions of RTSP used 7070 IIRC.

    John A.

  • 0 in reply to John Anderson
    Intellectual 370 points

    Here is the whole UDP payload (1448 bytes).

     

    80604af5943c160c326480657c018a9e626341384e87c0e5723f1498b9b25e6b2298e0909c6994811b3a37d7ce96f68116c7ad3632bcf17a0cf8227e45ccccf9c3de78c73c3c04f3918096fc7ad04b4a371e359beba2497cbee8f771af806a93896a5a9919e7fbf102049896d501d74873696bba25ea11449df7c0536467697e055cff8662f95dcac256283c619005fc378b3eea3a4e9ed9be55c188e514cf88845cbb54ce0756f7c941eb315664615964ee3abcc71d2a78909e67f65311a3e57245067947abde3c68f954869342a49cb590cc8e3f853388e0f47bc6598c5d9e1808e7b1ebd63024595cfc4e46efb68a9edb45cb447d737afc09ae443485e305a89fea6dac592d715177182c6e0831afe1bf36821ceebe31584eb024e2e727d6f8d15dc54d5372c5dfc006db24826d9c4623c81a854313c8c7407880a794ba485ccabf779fab1c9b10ce409d6c85da90a13d23e352cd3a9cd7baef4e782ddc73d031947c8767d00650a031c4ba35c7c8fa00b2b0c604a04aca10726ae2b9c835d8d48e40517560bb5e2c4ec2852409d758ff708dc6179c2d8cd11a0c53bff58b25b6da579977cfdefb4bfd878db7d31759b40790f10456c0d962513f3300ab643464b387acdbe8c331069b4f19894a54a184a4a2cdf8db732660acd4e8cd460a71107e353e01b2abe5ff3a0673d4014035a3792013294be047207e08783a9aa238df0d3c8bde82e4df344f76ed483738c1ba34344ee744626cdc5eddf342865809bb4981c0dcfb124898d15e30a7866d158392558d3132fabe98c4410b2a820014302bd8a3ef16eb60e55db559d9d7393c74b214f2c6a53758ee7aa7f700b0507aefb4af64fdb4813330bf95a8665a2be736c0326ea16d07a9cb18e447ed0bd4033b219d6499701d3daed8653f3549e456fd2f2b963ee7493d46b3e816e010c1b61c9cb278f8c19ca0fb318fb1edd29afcc167f2d0b64cb96854dcfa5533aac3741a33f16b6b6a14a23e50ac588e0cd975e83c7287955f25649149e59d3a41c991b17b8a6d547e63800c8bbe0ad46bf4568063c4d96d9ea4937e48f5b51edaf6086cc30004f096ae318a7beb8c650e32f741c4e0e6a7188fad7d4602590c29997c65830fbff51ac34261fc4552716353624ac2f2e4cb6431d307a25146a3c4035eb77cbd4bc4e61d98d06e1f25a36d696e9a67acdb15af06148dc75a9330fbca33eb1bec6320a69fa4f1ff30c0b8e676051dad9f4067e5cc20579f7186b6d196bfdac7a31ced47eb5c6b477d4e5d85d162042962f96b45b2db1ec27de1d5b32c170b7f9ec063eebdd70d7c061846c83b525ae6fc6b789ab48abbeb9293bc787a2f77dc08ede2e28e8b318c98492b108f28519fb0982debd174275b3f6cedb3484e29c05a88be041f701a033b49a97656a1a241ee163e720288d459695855e3972cdbd9c8f3b87e2ef5f40e8afc00391807574b32438f709f6a3d1ad9cc421fda6ae856a6357689dd49fe290a884209d8d37833d09c7e2cac91e50bcde9d44c3367ba10746625e1de7dcbd7465a17cfeda3f004c0003b6faff40e638272b55832ad54749af5e1aee0ecfd95faf326456f2212fd089d048a0f0f2fb4d9527271d8c676df5e55af3bbb31f5fb22e247c46ec039b15cf8ec651a907400234887e9d8d081dd535df4249b18efdbe293c3cac7df22e8c740b0c98d6e06b0f49f8374d5f4e5e1ccbebe1d4d689f63c8235c3f131946eee9b97f4fbacae166bad617ad23dc746c008f0d225397d4a94db1f7b290e3dceaf9adbe9ba2cde32815777af3564a1c6fdcce4f2def466adcd7050309a74622ca39656b4dafb8df3376f92fc9bb089f53c4686904abcf449e1230b9da6ff20969216ede93f70631efd3b31ec4bc7209de8ab35ec65f9764bf1c407ca444eb2ddc72298609efecbc4c8eb1fb68d574e1d149dab5b5d6135da9fe7ba5fb1f090a398dd394e3bbf37ba0a8ef2bccc3d1cd14633296242410b00f19eefd17b2e7b3e0633a8d1f631da34267a5392bea63897e0953ffd9a1

  • 0 in reply to bo yu54559
    Genius 5240 points

    That's RTP.

    John A

  • 0 in reply to John Anderson
    TI__Genius 11000 points

    That might be the image tuning tool ... we use raw TCP/IP socket 5000.
    Though no communication happens on it unless the tuning tool is connected to it.
    Also production systems should disable the tunning tool sever thread on IPNC.

    Some more details:
    By RFC2326(http://www.faqs.org/rfcs/rfc2326.html).  10.4 SETUP
     
    On RTSP negotiation, the client will send SETUP command to server like below
     
       C->S: SETUP rtsp://example.com/foo/bar/baz.rm RTSP/1.0
              CSeq: 302
              Transport: RTP/AVP;unicast;    client_port=4588-4589
     
    we'll see the client request RTP  on ports 4588 and 4589 for the data transport.
    The server responds with confirmation of the RTP  transport mechanism and
    the client-side ports and includes the unique Session ID and server port information.
     
     S->C: RTSP/1.0 200 OK
              CSeq: 302
              Date: 23 Jan 1997 15:35:06 GMT
              Session: 47112344
              Transport: RTP/AVP;unicast;
                client_port=4588-4589;server_port=6256-6257
     
    So, the port of destination is decided by the client and is not fixed.

    Regards,

    Raghu