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

AM69: Multi-Instance Support for v4l2h264dec/v4l2h265dec on AM69

Jason Lee
Prodigy 40 points
Part Number: AM69


Hi TI Team,

I am using EdgeAI SDK 08.06.00.12 on AM69-SK
I ran four gst-launch-1.0 pipelines simultaneously, and after around 4 hours, the system experienced a kernel panic.
My question is: do the v4l2h264dec and v4l2h265dec drivers support multi-instance usage?

Below are the pipelines I used:

gst-launch-1.0 \
rtspsrc location=rtsp://192.168.109.242/live_st1 \
do-retransmission=false do-rtcp=false drop-on-latency=true latency=200 protocols=tcp tcp-timeout=20000000 ! queue ! \
rtph264depay ! queue ! \
h264parse ! queue ! \
v4l2h264dec ! queue ! \
fakesink sync=false

gst-launch-1.0 \
rtspsrc location=rtsp://192.168.109.244/live_st1 \
do-retransmission=false do-rtcp=false drop-on-latency=true latency=200 protocols=tcp tcp-timeout=20000000 ! queue ! \
rtph264depay ! queue ! \
h264parse ! queue ! \
v4l2h264dec ! queue ! \
fakesink sync=false

gst-launch-1.0 \
rtspsrc location=rtsp://192.168.109.245/live_st1 \
do-retransmission=false do-rtcp=false drop-on-latency=true latency=200 protocols=tcp tcp-timeout=20000000 ! queue ! \
rtph264depay ! queue ! \
h264parse ! queue ! \
v4l2h264dec ! queue ! \
fakesink sync=false

gst-launch-1.0 \
rtspsrc location=rtsp://admin:@192.168.109.238:554 \
do-retransmission=false do-rtcp=false drop-on-latency=true latency=200 protocols=tcp tcp-timeout=20000000 ! queue ! \
rtph265depay ! queue ! \
h265parse ! queue ! \
v4l2h265dec ! queue ! \
fakesink sync=false

The kernel panic log snippet is as follows:
root@am69a-sk:/# [16657.351045] Unable to handle kernel paging request at virtual address dead000000000100
[16657.359690] Mem abort info:
[16657.362634]   ESR = 0x96000004
[16657.365827]   EC = 0x25: DABT (current EL), IL = 32 bits
[16657.371484]   SET = 0, FnV = 0
[16657.374559]   EA = 0, S1PTW = 0
[16657.377742] Data abort info:
[16657.380632]   ISV = 0, ISS = 0x00000004
[16657.384487]   CM = 0, WnR = 0
[16657.387469] [dead000000000100] address between user and kernel address ranges
[16657.394596] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[16657.400154] Modules linked in: xt_conntrack xt_MASQUERADE xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defr6
[16657.477620] CPU: 4 PID: 1517 Comm: queue2:src Tainted: G           O      5.10.162-g76b3e88d56 #1
[16657.486467] Hardware name: Texas Instruments AM69 SK (DT)
[16657.491849] pstate: 20000005 (nzCv daif -PAN -UAO -TCO BTYPE=--)
[16657.497851] pc : wave5_handle_bitstream_buffer+0xc4/0x1e0 [wave5]
[16657.503929] lr : wave5_handle_bitstream_buffer+0xf8/0x1e0 [wave5]
[16657.510004] sp : ffff800015013a40
[16657.513304] x29: ffff800015013a40 x28: 00000000c058560f 
[16657.518602] x27: 0000000000000000 x26: ffff000917513400 
[16657.523898] x25: ffff0008f81a7598 x24: 0000000000001b90 
[16657.529194] x23: 000000000000228f x22: deacfffffffffd58 
[16657.534490] x21: ffff80014362f000 x20: ffff0008f54c5800 
[16657.539787] x19: ffff00090da80000 x18: 0000000000000000 
[16657.545082] x17: 0000000000000000 x16: 0000000000000000 
[16657.550377] x15: 0000ffff9c02ac98 x14: 000000010004d80a 
[16657.555673] x13: 0000000000000000 x12: 0000000000000000 
[16657.560969] x11: 00000000000de889 x10: 0000000000003e0e 
[16657.566265] x9 : 0000000000000001 x8 : 0000000000000001 
[16657.571561] x7 : 0000000000000030 x6 : 000000000000000a 
[16657.576857] x5 : ffff0008f81a7af0 x4 : 0000000000000000 
[16657.582154] x3 : ffff0008f54c7000 x2 : dead000000000100 
[16657.587451] x1 : 0000000000000001 x0 : ffff0008f81a7000 
[16657.592750] Call trace:
[16657.595191]  wave5_handle_bitstream_buffer+0xc4/0x1e0 [wave5]
[16657.600926]  wave5_vpu_dec_buf_queue+0x7c/0x300 [wave5]
[16657.606139]  __enqueue_in_driver+0x5c/0x68 [videobuf2_common]
[16657.611869]  vb2_core_qbuf+0x464/0x5f0 [videobuf2_common]
[16657.617254]  vb2_qbuf+0x8c/0xe0 [videobuf2_v4l2]
[16657.621863]  v4l2_m2m_qbuf+0x80/0x218 [v4l2_mem2mem]
[16657.626815]  v4l2_m2m_ioctl_qbuf+0x18/0x28 [v4l2_mem2mem]
[16657.632204]  v4l_qbuf+0x48/0x60
[16657.635332]  __video_do_ioctl+0x184/0x3e8
[16657.639328]  video_usercopy+0x18c/0x580
[16657.643149]  video_ioctl2+0x18/0x58
[16657.646627]  v4l2_ioctl+0x40/0x60
[16657.649930]  __arm64_sys_ioctl+0xa8/0xf0
[16657.653840]  el0_svc_common.constprop.0+0x78/0x1c8
[16657.658614]  do_el0_svc+0x24/0x90
[16657.661918]  el0_svc+0x14/0x20
[16657.664960]  el0_sync_handler+0xb0/0xb8
[16657.668781]  el0_sync+0x180/0x1c0
[16657.672085] Code: 52800020 390ee280 f9404e60 910ea2c2 (f941d6c1) 
[16657.678164] ---[ end trace 87860189ba011fd7 ]---

Best Regards,
Jason Lee

  • 0
    TI__Guru** 116770 points

    Hi Jason,

    Please update your SDK baseline to SDK 10.1. SDK 8.06 is outside TI support window.  

    Thanks and Regards,

    Rahul Prabhu 

  • 0 in reply to Rahul Prabhu
    Prodigy 40 points

    Hi ,

    I'm currently testing with SDK 11.01.00 and building the tisdk-edgeai-image.

    I’m running four RTSP pipelines (on weston terminals). Sometimes they all work fine,

    but occasionally one or more of them hang and show the following warning:


    ** (gst-launch-1.0:1314): WARNING **: 07:11:38.348: v4l2h264dec0: 29 initial fra
    mes were not dequeued: bug in decoder -- please file a bug

    When this happens, pressing Ctrl+C does not terminate the process.

    All RTSP streams are 1080p. Three are H.264 (30 fps) and one is H.265 (20 fps).
    Below are the pipelines I’m using:

    # Camera 1
    GST_DEBUG=2 gst-launch-1.0 \
    rtspsrc location=rtsp://192.168.109.242/live_st1 \
    do-retransmission=false do-rtcp=true drop-on-latency=true latency=200 protocols=tcp timeout=60000000 ! queue ! \
    rtph264depay ! queue ! \
    h264parse ! queue ! \
    v4l2h264dec ! queue ! \
    fakesink sync=false

    # Camera 2
    GST_DEBUG=2 gst-launch-1.0 \
    rtspsrc location=rtsp://192.168.109.244/live_st1 \
    do-retransmission=false do-rtcp=true drop-on-latency=true latency=200 protocols=tcp timeout=60000000 ! queue ! \
    rtph264depay ! queue ! \
    h264parse ! queue ! \
    v4l2h264dec ! queue ! \
    fakesink sync=false

    # Camera 3
    GST_DEBUG=2 gst-launch-1.0 \
    rtspsrc location=rtsp://192.168.109.245/live_st1 \
    do-retransmission=false do-rtcp=true drop-on-latency=true latency=200 protocols=tcp timeout=60000000 ! queue ! \
    rtph264depay ! queue ! \
    h264parse ! queue ! \
    v4l2h264dec ! queue ! \
    fakesink sync=false

    # Camera 4 (H.265)
    GST_DEBUG=2 gst-launch-1.0 \
    rtspsrc location=rtsp://admin:@192.168.109.238:554 \
    do-retransmission=false do-rtcp=true drop-on-latency=true latency=200 protocols=tcp timeout=60000000 ! queue ! \
    rtph265depay ! queue ! \
    h265parse ! queue ! \
    v4l2h265dec ! queue ! \
    fakesink sync=false

    Could you please advise if there are any recommended changes to these pipelines, or known issues with v4l2h264dec / v4l2h265dec under SDK 11.01.00?

    Best Regards,
    Jason Lee