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

TMS320DM365 H.264 video encoder

Shahzad Malik97479
Intellectual 295 points

I have been evaluating TI's DM365 as a potential H.264 video encoding solution.

 

I have been using the Leopboardboard DM365 (see http://shop.leopardimaging.com/product.sc?productId=53)

 

and for the camera, the LI-5M03 5M MT9P031 Camera Board.

(see http://shop.leopardimaging.com/product.sc?productId=17)

 

For software, I have been using RidgeRun's evaluation SDK.

(https://www.ridgerun.com/developer/wiki/index.php/EVAL_SDK_2011Q2_for_DM365_Leopard_Board)

 

For the most part, the system seems to be working fine, but something seems to be grossly wrong with the H.264 encoding.  With every I-frame, the shading seems to change, which persists throughout the subsequent P-frames.  The next I-frame introduces different shading.  Also, there seem to be artifacts in the produced video that are way worse than would be expected at the encoded bit rate.  

 At this point, I am looking for some guidance about how to follow up with this problem.

I.e. should it be with TI, or Leopard, or RidgeRun?  

 

  • 0
    Prodigy 60 points

    Hi, we use exactly the platform you describe above (Leopardboard DM365 / DM368 + MT9P031 5MP camera, RRSDK 2011Q2).

    RRSDK2011Q2 requires the TI DVSDK4, this has the 'platinum' high profile H.264 codec.  The H.264 encoding works fine for us and we get nice results at 30fps HD resolution.  If the bitrate is restricted we observe the expected blockiness in fast changing scenes, but there's no issue with colour.

    We did not have to modify anything in the SDK or the DVSDK to get the codecs to work properly.  We did however apply several small modifications to the RRSDK kernel and configuration, to provide extended or missing functionality.  One important change is that we replace the MT9P031 driver completely with our own custom driver.  We have experienced colour issues with the SDK driver in the past.  It may be possible that the standard driver produces flawed video and this prevents the H.264 encoder from working normally.

    How do you run the codec?  We do not use the GStreamer TI plugins for this purpose, nor the TI sample applications.  Maybe there is a bug in those components.

    What we actually do is capture capture and encode the video in our own C application.  This was developed using the TI sample capture/previewer/resizer and 'encode' demos as a starting point.  We integrated transport of the H.264 by incorporating calls to the GStreamer library which send the encoded H.264 packets via the appsrc element over various transports, to server targets running in parallel on the Leopardboard. (For example send out RTP packets over UDP to Darwin Streaming Server for RTSP delivery, or send straight UDP packets to crtmpserver for RTMP delivery).  We followed this approach because it is highly customizable at a low level and allows us to build in specialized realtime features for our requirements.

  • 0 in reply to Mark Lesha
    Prodigy 10 points

    Hello,

    We are being asked to develop a system very similar to the one described here for a medical company (5 Megapixel, H.264, 1394-S800).

    We need to get H.264 compression in the camera and operate over 1394-S800. Has anyone attempted this before? Does anyone have any ideas or references to point us to? Does DaVinci have the horsepower to do this in real-time? Any replies gratefully appreciated!