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.

MSCDK VIDEO sv01 demo's RTP payload format could not be parsed by video tools

Hi Champs,

                 My customer want to know which RTP payload format is used for sv01 demo? They want use video tools to analysis transcoded streams but failed. The error screen is as below. 

                 Do you have any idea on it? Thanks a lot! 

                Jane

  • Hi Jane form the functional specs we have:

    2.1.1 RTP Support

    Description

    If the channel is configured for RTP operation, the data is encapsulated in accordance with the RFC 1889/3550 specification. The Multicore Video Infrastructure Demo for C66x Processors software leverages RTP Support from Voice. Refer to TI MAS Spec.

     http://software-dl.ti.com/sdoemb/sdoemb_public_sw/mcsdk_video/latest/exports/mcsdk_video_functional_spec_02_00_00.pdf

    But I will double check with the developers and let you.

    thanks,

    Paula

  • Hi Paula,

               My customer feedback that RFC 1889/3550 is for RFC head and they would like to know the RFC payload format of demo sv01.

              mcsdk_video_functional_spec_02_00_00.pdf section2.1.4 mention that RFC3984 is defined for H264 format and it consists several kinds format.  

             With demo SV01,  my customer reported that the H.264 streams send from PC to Shannon board is based on FU-A format and the package can be parsed by protocol tools successfully. But the H.264 output stream sent from Shannon to PC can not be parsed by protocol tools. They would like to know which RFC3984 format is used on demo sv01. 

               Thanks again for your help! 

               Jane

  • Hi Jane,

    We use the following NALU types (rfc3984SendIn in ti\mas\rfcs\src\video\RFC3984\rfc3984.c)

    • NALU_TYPE_SEI
    • NALU_TYPE_SPS
    • NALU_TYPE_PPS
    • NALU_TYPE_IDR (FU_A)
    • NALU_TYPE_NON_IDR_PIC (FU_A)

     In summary we use FU-A format. It would be a goodt idea if you can please help us to get the cap file with which they are having trouble parsing, so we can test them.

    thanks,

    Paula 

  • Hi Jane, as I mentioned by email our parser works OK and output streams don't show any error (when opening them with Vega analyser). Do you know which parser application is your costumer using? by any chance it is an open source that we can get and take a look?

    thank you,

    Paula