• State TI Thinks Resolved
  • Locked Locked
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 101 subscribers
  • Views 201 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

AM69: Inquery about AM69 Video Decoding Performance

Jack Cha
Mastermind 8154 points
Part Number: AM69

Hi AM69 Champ !

My customer is tring to implement multiple network camera based encoding and decoding system using AM69. 

Can you please clarify the following questions?

[Q1] TRM page 12 states that 8x 1080p30 encoding or decoding can be processed concurrently, please confirm if it is possible to decode at least 12 at D1 level at the same time, and how many at most.

[Q2] 2) If I run multiple gst-launch-1.0's like the GStreamer usage example in the docs, will they all behave to use the Dec. Accelerator?
Also, what is the maximum resolution of each Decode?

[Q3] What are the possible combinations when outputting more than one decoded video (2x2, 3x3, or any of the 1 to 12 camera views with coordinates?)
It looks like they are asking about something like the following CCTV split screen.

[Q4] When decoding H.264/H.265, does it support B-Frame?

Thanks a lot.

Best Regards, 

Jack 

 

  • 0
    TI__Genius 10420 points

    Hi Jack, 

    Jack Cha said:
    [Q1] TRM page 12 states that 8x 1080p30 encoding or decoding can be processed concurrently, please confirm if it is possible to decode at least 12 at D1 level at the same time, and how many at most.

    I don't believe we have any test-cases for 12 streams of 720x480 at 30 fps. So I can't confirm right now if this is possible or not. I will try to run some tests to see if the IP is capable of the processing power required for this use case. 

    Jack Cha said:
    [Q2] 2) If I run multiple gst-launch-1.0's like the GStreamer usage example in the docs, will they all behave to use the Dec. Accelerator?
    Also, what is the maximum resolution of each Decode?

    Yes, when you use the v4l2h264dec/v4l2h265dec element in the GStreamer pipeline, this will take use of the codec h/w accelerator. The maximum resolution supported without fps being taken into account is 8192x4320 for encode/decode. With taking in real time performance into account, we can guarantee up to 4k60 (3840x2160) per encoder/decoder.

    Jack Cha said:
    [Q3] What are the possible combinations when outputting more than one decoded video (2x2, 3x3, or any of the 1 to 12 camera views with coordinates?)
    It looks like they are asking about something like the following CCTV split screen.

    It would depend on how many streams the VPU is able to process at 720x480 at 30fps. Will get back to you on this.

    Jack Cha said:

    [Q4] When decoding H.264/H.265, does it support B-Frame?

    No, B-Frames are not supported by this codec IP.

    Thanks,
    Sarabesh S.

  • 0 in reply to Sarabesh Srinivasan
    TI__Genius 10420 points

    Hello Jack, 

    I can confirm that the VPU is able to process 12 streams of 720x480 @30fps. This can be shown with the following pipeline and latency results:

    • GST_DEBUG_FILE=gst_trace.log GST_DEBUG_NO_COLOR=1 GST_DEBUG="GST_TRACER:7" GST_TRACERS="latency(flags=element):v4l2" gst-launch-1.0 filesrc location=airshow_p720x480_nv12.264 ! h264parse ! tee name=t \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink \
      t. ! queue ! v4l2video2h264dec capture-io-mode=4 ! fakevideosink

    This is split by having 6 channels run on one VPU and 6 channels running on the second VPU.

    I ran the same command with 8 channel decoder per VPU instance and found that the latency increased by ~2ms. It seems safe to assume that your use-case is supported based on these results. Since the each VPU has a maximum pixel processing rate at ~523MP/s as long as the use-case is under this then you should have no issues. Let me know if something comes up.

    BR,
    Sarabesh S.