• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 98 subscribers
  • Views 172 views
  • Users 0 members are here
Support feedback
Options
Options
Related

TDA4VEN-Q1: Time consumption issue of v4l2h265enc

xie jc
Expert 2180 points
Part Number: TDA4VEN-Q1

Tool/software:

Hi TI experts,

SDK:10.0

Linux:10.0

HW:our own board

data flow：capture node->ldc node->v4l2 encode->rtp->IHU decode

We used v4l2h265enc in the project and occasionally encountered screen freezing issues during debugging. I understand that video codecs are hardware codecs and theoretically will not be affected by SOC CPU resources, resulting in longer encoding time. Is there any method, such as adding logs or using some features, that can help us analyze whether the encoding process, including content and time consumption, is normal?

BR.

  • 0
    TI__Guru**** 476925 points

    Hi xie jc,

    Just like the other thread, my suggestion is to first check if WDG in LDC is enabled.. So can you please check and make sure to disable WDG in LDC? 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 2180 points

    Hi Brijesh，

    Based on your suggestion, we will disable WDG in LDC on all TDA4 platforms.

    Based on existing experience, when there is an abnormality displayed on the IHU (screen freeze or flashing), we often need to prove whether every node on the data flow is normal. For a node v4l2h265enc, what methods do we have to confirm whether the encoded content and encoding time are normal?

    BR.

  • 0 in reply to xie jc
    TI__Guru**** 476925 points

    Hi xie jc,

    I am not sure the exact time for the encoder. You should probably profile the time it takes for encoding in system usecase and use this time to figure out if it is working fine. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 2180 points

    Hi Brijesh,

    Yes, I know what you mean. Under normal circumstances, the encoding time is within 20ms, and I am not sure if this time is a normal time. But the current problem is that when the image display on the IHU lags, I need to confirm the encoding time of V4L2H265ENC, because some people question that the encoding time is too long when there is an exception. Therefore, I need to know the encoding time of V4L2H265ENC through logs, calculation methods, or official data

    BR.

  • 0 in reply to xie jc
    TI__Guru**** 476925 points

    Hi xie,

    ok, i will request my colleague   to help you in this case. 

    Regards,

    Brijesh

  • 0 in reply to Brijesh Jadav
    Expert 2180 points

    Hi Brijesh,

    Thank you for your support. 
    On the one hand, we want to increase the log to view the actual time spent running the code on the current project (but I'm not sure where the hardware code is actually called in the source code in the current v4l2 driver). On the other hand, we have some official data to support our analysis of the problem, which is the best approach.

    BR.

  • 0 in reply to xie jc
    TI__Genius 16680 points

    Hello, 

    If you're using the encoder through GStreamer then you can add logs with enabling GStreamer debug logs using GST_TRACER (here). 

  • 0 in reply to Sarabesh Srinivasan
    Expert 2180 points

    Hi Sarabesh S,

    We did not using the encoder through GStreamer,the data flow are as follow:capture node->ldc node->v4l2 encode->rtp->IHU decode.

    BR.

  • 0 in reply to xie jc
    TI__Genius 16680 points

    Hello,

    Thanks for the clarification. If you're looking to log the encoding time for the stream then you would do this in V4L2 application rather than the driver source code particularly around the v4l2_m2m_ioctl_qbuf and v4l2_m2m_ioctl_dqbuf. Start the timestamp after enqueuing and end the timestamp after dequeuing and returning the buffer. 

    Thanks,
    Sarabesh S.