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.

DM8168 Bulk Video Decode

I am evaluating the DM8168 SoC using the Spectrum Digital EVM.  I would like to determine the maximum number of video channels the DM8168 can decode.

My usecase will be multiple channels of encoded video (MPEG2/MPEG4) coming in via the PCIe interface.  The video will then be decoded to raw YUV video and go out the PCIe interface.  I am interested in the maximum number of D1 resolution channels the DM8168 can support.

It is not clear which software API should be used for the best performance of multiple channel decodes (gstream, OMX, CODEC Engine, etc).

I am using the EZSDK 5_04_00_11.  For a starting point I am able decode one mpeg stream from the SDHC root file system and have it displayed on the attached HDMI monitor using gstreamer.

I tried to modify the gstream pipeline to send the video to a remote server using TCP.  When I do this, the performance drops to 20 FPS, and the arm-load reaches 100% with the remote server is connected.

This is the pipeline that I am using:

gst-launch -v filesrc location=001-rs.ts typefind=true ! mpegtsdemux ! mpegvideoparse ! omx_mpeg2dec ! omx_scaler ! gstperf ! tcpserversink

Is there something that can be done to improve the performance of this gstreamer pipeline?

What is the best API to be using to get multiple channels of video decode working on the DM8168?

  • Hello,

    I tried this pipeline:

    gst-launch -v filesrc location=/usr/share/ti/data/videos/sample5.ts typefind=true ! mpegtsdemux ! mpegvideoparse ! omx_mpeg2dec  ! omx_scaler ! gstperf ! tcpserversink

    On my side there was no problem with the FPS. In your case the arm-load reach 100% because your FPS drop.

    For multiple channels of video decode you could use OMX.

    Best Regards

    Margarita

  • Hello,

    Thank you for responding.

    I should have noted that the load is fine if there is no socket connected to the tcpserver sink.  Here is the output with no socket connected:

    Pipeline is PREROLLED ...                                                       
    Setting pipeline to PLAYING ...                                                 
    New clock: GstSystemClock                                                       
    perf0: frames: 10       current: 9.91    average: 9.91  arm-load: 1             
    perf0: frames: 40       current: 29.97   average: 19.90 arm-load: 22            
    perf0: frames: 70       current: 29.96   average: 23.25 arm-load: 23            
    perf0: frames: 100      current: 29.98   average: 24.93 arm-load: 10            
    perf0: frames: 130      current: 29.95   average: 25.93 arm-load: 14

    Once I connect a remote VLC client to view the raw video, using the command:

    vlc --demux rawvideo --rawvid-fps 30000/1001 --rawvid-width 720 --rawvid-height 480 --rawvid-chroma=YUY2  tcp://192.168.0.123:4953

    The load increases:

    Pipeline is PREROLLED ...                                                       
    Setting pipeline to PLAYING ...                                                 
    New clock: GstSystemClock                                                       
    perf0: frames: 10       current: 9.78    average: 9.78  arm-load: 1             
    perf0: frames: 36       current: 25.64   average: 17.67 arm-load: 100           
    perf0: frames: 58       current: 21.91   average: 19.07 arm-load: 100

    I also tried writing the data to an output file on a SATA drive and a SATA SSD with similar results.

    it appears that the pipeline is not using DMA.  Do I need to add an omxbufferalloc to the pipeline?

    Best Regards,

    Tim

  • Hello Tim,

    omxbufferalloc: Buffer allocater element used to allocate buffers that can be passed to OMX elements. E.g. V4L2 capture uses this to allocate buffers, which then can be passed to omx_h264enc without incurring a buffer copy.

    Best Regards,

    Magy

  • Hello Tim,

    You could try this:

    remote VLC client:

    vlc  tcp://192.168.1.22:4953

    EVM:

    gst-launch -v filesrc location=/usr/share/ti/data/videos/sample5.ts typefind=true ! mpegtsdemux ! mpegvideoparse  ! gstperf ! tcpserversink

    perf0: frames: 446     current: 28.80     average: 29.31    arm-load: 33
    perf0: frames: 476     current: 29.95     average: 29.35    arm-load: 34
    perf0: frames: 506     current: 29.98     average: 29.38    arm-load: 40
    perf0: frames: 536     current: 29.95     average: 29.41    arm-load: 46
    perf0: frames: 567     current: 30.62     average: 29.48    arm-load: 44
    perf0: frames: 597     current: 29.84     average: 29.50    arm-load: 40
    perf0: frames: 628     current: 30.77     average: 29.56    arm-load: 39
    perf0: frames: 658     current: 29.97     average: 29.57    arm-load: 36
    perf0: frames: 688     current: 29.93     average: 29.59    arm-load: 35

    The idea is that  you do not decode the video stream on EVM, but to leave the decode part to the player, in order to improve the performance.

    Best Regards,

    Margarita


  • Hello Margarita,

    What is the bit rate of the sample5.ts file?  Is it available for download?

    The arm load still seems fairly high if the 8168 is no longer doing the decoding, which reinforces my suspicion that the writes to the network are not using DMA.

    Since I am trying to benchmark the number of decodes the 8168 can perform, I do not want to offload the decoding to the remote VLC client.

    I also tried writing the output to a SATA SSD using filesink and had similar results.

    Is there anything I can do to the gstreamer pipeline to increase the performance?

    Best Regards,

    Tim

  • Hello,

    You could check here for examples:

    http://processors.wiki.ti.com/index.php/DM81xx_Gstreamer_Pipelines

    You could try to use RTSP/RTP.

    Best regards,

    Margarita