Part Number: TDA4VM
Hi team,
SDK version: 8.04
To enable real-time decoding of the h264 code stream (encoded by YUV420P), the customer created the following pipline in the software:
sprintf(cmd, "appsrc format=GST_FORMAT_TIME is-live=true do-timestamp=true block=true name=appsrc ! queue \
! h264parse \
! video/x-h264, parsed=true, stream-format=byte-stream, alignment=au \
! v4l2h264dec \
! video/x-raw, format=(string)I420 \
! appsink name=appsink drop=true async=false sync=false buffer-list=true enable-last-sample=false wait-on-eos=false max-buffers=50 \n");
GstElement *pipeline;
pipeline = gst_parse_launch(cmd, NULL);
In the loop, write the H264 stream data (one nalu at a time) to the ‘appsrc’ plug-in via gst_app_src_push_buffer.
Outside the loop, via g_signal_connect(appsink, "new-sample", G_CALLBACK(new_sample_callback) NULL; bind new_sample_callback to the signal, new-sample, of 'appsink' to get the decoded data. However, some duplicate logs are printed:
[ 144.581716] ------------[ cut here ]------------ [ 144.588847] WARNING: CPU: 0 PID: 206 at drivers/media/platform/vxe-vxd/decoder/vdecdd_utils_buf.c:665 vdecddutils_get_render_info.isra.0+0x314/0x368 [vxd_dec] [ 144.606515] Modules linked in: ipv6 spidev spi_omap2_mcspi pvrsrvkm(O) cryptodev(O) vxe_enc vxd_dec v4l2_mem2mem videobuf2_dma_contig videobuf2_dma_sg videobuf2_memops videobuf2_v4l2 videobuf2_common ti_j721e_cpsw_virt_mac rpmsg_kdrv_switch rpmsg_char ti_k3_dsp_remoteproc ti_k3_r5_remoteproc virtio_rpmsg_bus [ 144.640584] CPU: 0 PID: 206 Comm: v4l2h264dec0:sr Tainted: G W O 5.10.120-g95b90aa828 #1 [ 144.652076] Hardware name: Texas Instruments K3 J721E SoC (DT) [ 144.659346] pstate: 60000005 (nZCv daif -PAN -UAO -TCO BTYPE=--) [ 144.666844] pc : vdecddutils_get_render_info.isra.0+0x314/0x368 [vxd_dec] [ 144.675314] lr : vdecddutils_get_render_info.isra.0+0x2f8/0x368 [vxd_dec] [ 144.683772] sp : ffff800012833830 [ 144.687898] x29: ffff800012833830 x28: ffff0008295fb9e0 [ 144.694517] x27: ffff8000128338cc x26: ffff8000128338c8 [ 144.701137] x25: 0000000000000500 x24: ffff8000128338c8 [ 144.707758] x23: 0000000000000500 x22: ffff8000128339a4 [ 144.714379] x21: ffff00082a58e200 x20: ffff8000128339b8 [ 144.720998] x19: 0000000000000001 x18: ffff00082a4a9428 [ 144.727618] x17: 0000000000000000 x16: 0000000000000000 [ 144.734237] x15: 0000ffff7800ca28 x14: 00000000000002d0 [ 144.740856] x13: 0000050000000000 x12: 0000000000000000 [ 144.747476] x11: 0000000000000001 x10: 0000000000000001 [ 144.754096] x9 : 0000000000000002 x8 : ffff8000128339c0 [ 144.760716] x7 : ffff8000128338b8 x6 : ffff00082a4a2028 [ 144.767337] x5 : ffff800008b54e28 x4 : 000000000001500f [ 144.773957] x3 : 00000000000000ff x2 : 00000000000002d0 [ 144.780576] x1 : 0000000000000500 x0 : 00000000000000ff [ 144.787197] Call trace: [ 144.790252] vdecddutils_get_render_info.isra.0+0x314/0x368 [vxd_dec] [ 144.798289] vdecddutils_pictbuf_getinfo+0x20/0x70 [vxd_dec] [ 144.805352] core_check_decoder_support.isra.0+0xa8/0x168 [vxd_dec] [ 144.813173] core_stream_submit_unit+0x530/0xee0 [vxd_dec] [ 144.820019] device_run+0x320/0x380 [vxd_dec] [ 144.825458] v4l2_m2m_try_run+0x84/0x138 [v4l2_mem2mem] [ 144.831970] v4l2_m2m_qbuf+0x104/0x218 [v4l2_mem2mem] [ 144.838265] v4l2_m2m_ioctl_qbuf+0x18/0x28 [v4l2_mem2mem] [ 144.844999] v4l_qbuf+0x48/0x60 [ 144.848910] __video_do_ioctl+0x184/0x3e8 [ 144.853904] video_usercopy+0x18c/0x580 [ 144.858680] video_ioctl2+0x18/0x58 [ 144.863027] v4l2_ioctl+0x40/0x60 [ 144.867159] __arm64_sys_ioctl+0xa8/0xf0 [ 144.872047] el0_svc_common.constprop.0+0x78/0x1c8 [ 144.878015] do_el0_svc+0x24/0x90 [ 144.882146] el0_svc+0x14/0x20 [ 144.885947] el0_sync_handler+0xb0/0xb8 [ 144.890724] el0_sync+0x180/0x1c0 [ 144.894851] ---[ end trace 0d665693e085a6f2 ]---
The decoded data is also not the YUV420P that the customer wants. The customer would like to know is there a problem with the above pinline design Or is the v4l2h264dec plugin issue?
Could you help check this case? Thanks.
Best Regards,
Cherry
