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.

TDA4VL-Q1: H264 Encoder performances Evaluation for two 3M pixel camera @30FPS

Part Number: TDA4VL-Q1
Other Parts Discussed in Thread: TDA4VL, TDA4VM

Tool/software:

Hi, Dear Expert.

We already reference this thread, and try to evaluate H264 encoder performance for TDA4VL.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1324982/tda4vl-q1-h264-encoder-performances/5042643?tisearch=e2e-sitesearch&keymatch=tda4vl%20encode#5042643

This thread tells us, TDA4VL support 1x1080p@120FPS (2M pixel camera) work well, but it seems have some performance insufficient issues for 2x1080p@60FPS. (Frame lost)

My question : 

(1) Is it spec. limitation for TDA4VL? How does frame lost happen? Any update?

(2) Does TDA4VL support "two" 3M (2048x1536) pixel camera @30FPS? How about encoder latency?

(3) As far as I know, encoder support YUV420 or NV12, which format has better encoding performance for low latency?

Many Thanks

Gibbs

 

  

  • Hi,

    Please expect a delay in response due to holiday in US on 27 May 2024.

    Regards,

    Nikhil

  • Hi Gibbs, 

    (1) Is it spec. limitation for TDA4VL? How does frame lost happen? Any update?

    Thanks for following up. After looking into the spec, although my test showed that 1x1080@120 was successful, I cannot provide any real-time guarantee for encoding framerates over 60fps. This is because the maximum encoding framerate we note in the TRM (section 6.6 Video Accelerator) is 60fps. Anything above may be result in buffer drop or lower output fps due to it being outside the hardware limitations.

    In the case of 2x1080@60, this is close the maximum supported pixel rate of the TDA4VL but should still be supported based on the spec. I will run this test to confirm results on the latest SDK. 

    (2) Does TDA4VL support "two" 3M (2048x1536) pixel camera @30FPS? How about encoder latency?

    As long as the camera is a CSI camera the connection should be supported. If you have a specific camera model I can check that for you. We don't have any latency measurements on this particular resolution but you can determine the QNX encoder performance metrics by following these steps HERE

    (3) As far as I know, encoder support YUV420 or NV12, which format has better encoding performance for low latency?

    NV12 is typically more efficient format due the interleaved layout of the U and V chroma components.

    Best,
    Sarabesh S.

  • Hi, Sarabesh

    Thanks your detail explanation.

    I agree with your opinion, CSI-RX/VPAC bandwidth & performance should be not problems for two 3M (2048x1536), customer use RAW camera (RAW8/10), The only concern is encoder performance.

    Could you also help me answer this thread? This is related thread.

    https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1366191/tda4vm-q1-how-to-correct-evaluate-encoder-performance-by-gstreamer?tisearch=e2e-sitesearch&keymatch=%252520user%25253A533255#

    We try to find a way for multi-camera encoder (h264) simulation, and we hope this way can approach TDA4AL/VL/entry for encode performance evaluation.

    I think these E2E threads should be good lession learn for whom has similar problems.

    Thanks again.

    Gibbs

  • Hi Gibbs, 

    What SDK and version are you using? The two threads you referenced are using different HLOS. 

    BR,
    Sarabesh S.

  • Hi Sarabesh

    Yes, they use different HLOS (platform), PSDKLA 9.x

    But I think it does not matter. The goal of these threads, try to find an common way to "real" evaluate encoder in different platform.

    Gstreamer plugin already include HW (accelerator) encoder, even TDA4VM/AL/VL both support gstreamer

    Many Thanks

    Gibbs

  • Hi Gibbs,

    The latency measured from the QNX and Linux would in fact differ due to the differences in the software driver stack, middle wear infrastructure, and general kernel architecture. There is no common method to determine latency from the v4l2h264enc GStreamer element and the QNX encoder test app since they operate with different application layer frameworks.

    For Linux, you can refer to this FAQ (HERE) to measure codec latency.
    For QNX you can refer to the SDK documentation (HERE) to measure codec latency.

    Thanks,
    Sarabesh S.