• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 384 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.

DVSDK (DM365/DM368) trans-code sample

Cullum Baldwin
Prodigy 210 points

We are trying to trans-code a file/stream from MPEG4 to H264 in real-time.  Using the DMAI samples in the 4.0X DVSDK, I was able to decode an MPEG4 file into a "named pipe" and then re-encode the video into an H264 file.  However due to file IO this is VERY slow (2-4 frames per second).

Are there any samples showing a dedicated "trans-code" like this?  Can the hardware support an encode/decode in parallel?  I tried combining the encode and decode samples into a single application, but I am unclear how the memory buffers need to be passed between the encode/decode codecs.

Thanks,

Cullum

  • 0
    TI__Intellectual 2785 points

    Cullum,

              File I/O is CPU consuming one, you can not do file IO, which might be the bottle neck, on solving (use over network) this it might improve the frame count.

              This usecase still might be a bottle neck for Video processing, which might not make it achive realtime, I will get back actual number for this for DM36X platform.

              For this usecase the buffer management needs to be handled by Application. Refer to DMAI documentation at <DVSDK-root>dmai_<rel-num>\docs\html

             The documents in <DVSDK-root>\codecs-dm365_<rel-num>\packages\ti\sdo\codecs\h264dec\docs also would give more details on buffer flow.

    Thanks & Regards

    Velan

  • 0 in reply to Velan
    Prodigy 210 points

    I have been able to setup transcode using a named pipe (mkfifo) and the DMAI video_encode/video_decode samples.  I got around the disk IO issues by sending the data in/out over the network.  However sending data through the "named pipe" seems to be as slow as disk access.  Ugh, is this always the case?  Can a named pipe be fast?

    Thanks,

    Cullum