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.

Trouble Capturing 720p60.

Other Parts Discussed in Thread: TVP7002, TLC59108

Hi,

I am using gstreamer to capture and preview live 720p60 video on the DM8148 EVM (I have the HDVICP2 running at 410 MHz), and am routinely running into a loss of buffers issue (see attached text).  The preview mode starts to work (I get a couple of frames of video on the LCD) before the error.  Is there something I need to add to the stream request for buffering or using the VPSS?

-Mike

----  Output

root@dm814x-evm:~# gst-launch v4l2src device="/dev/video0" always-copy=false queue-size=16 num-buffers=5000 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1280,height=720,framerate=(fraction)60/1' ! omxbufferalloc numBuffers=16 ! omx_scaler ! video/x-raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE_720P_60 display-device=LCD ! gstperf ! omx_videosink sync=false display-device=LCD
Setting pipeline to PAUSED ...

tvp7002_s_dv_preset: 8 Mode set is 720P60

allocating 16 buffers of size:1382400!!
allocated outbuf:0x441b8080
allocated outbuf:0x44309880
allocated outbuf:0x4445b080
allocated outbuf:0x445ac880
allocated outbuf:0x------------[ cut here ]------------
WARNING: at kernel/softirq.c:159 local_bh_enable+0x54/0xc4()
Modules linked in: bufferclass_ti omaplfb pvrsrvkm tlc59108 ti81xxhdmi ti81xxvin ti81xxvo ti81xxfb vpss tvp7002 syslink ipv6
Backtrace:
[<c004abd0>] (dump_backtrace+0x0/0x110) from [<c03d8ee8>] (dump_stack+0x18/0x1c)
r7:00000000 r6:c0074d08 r5:c04ae5e8 r4:0000009f
[<c03d8ed0>] (dump_stack+0x0/0x1c) from [<c006f770>] (warn_slowpath_common+0x54/0x6c)
[<c006f71c>] (warn_slowpath_common+0x0/0x6c) from [<c006f7ac>] (warn_slowpath_null+0x24/0x2c)
r9:c056726c r8:d088c780 r7:0000000d r6:ccaa2900 r5:c053e8a0
r4:c0592a00
[<c006f788>] (warn_slowpath_null+0x0/0x2c) from [<c0074d08>] (local_bh_enable+0x54/0xc4)
[<c0074cb4>] (local_bh_enable+0x0/0xc4) from [<c00695e8>] (omap_mbox_msg_send+0xcc/0xdc)
r5:c053e8a0 r4:00000000
[<c006951c>] (omap_mbox_msg_send+0x0/0xdc) from [<c030ba0c>] (notify_shm_drv_send_event+0x1c8/0x208)
r5:00000001 r4:00000000
[<c030b844>] (notify_shm_drv_send_event+0x0/0x208) from [<c030919c>] (notify_send_event+0x114/0x26c)
[<c0309088>] (notify_send_event+0x0/0x26c) from [<bf196a08>] (vps_fvid2_queue+0xe4/0x21c [vpss])
[<bf196924>] (vps_fvid2_queue+0x0/0x21c [vpss]) from [<bf19fccc>] (capture_queue+0x50/0x64 [vpss])
r8:bf1d1524 r7:60000013 r6:cc2ce580 r5:00000000 r4:cb780400
[<bf19fc7c>] (capture_queue+0x0/0x64 [vpss]) from [<bf1d02d0>] (ti81xxvin_buffer_queue+0x9c/0xe8 [ti81xxvin])
r5:cb75b800 r4:cb780400
[<bf1d0234>] (ti81xxvin_buffer_queue+0x0/0xe8 [ti81xxvin]) from [<c02e2994>] (videobuf_streamon+0x80/0xd0)
r7:60000013 r6:cb75b9c4 r5:cb75b904 r4:cc2ce580
[<c02e2914>] (videobuf_streamon+0x0/0xd0) from [<bf1cfd48>] (vidioc_streamon+0x244/0x400 [ti81xxvin])
r7:cc0d6200 r6:00000001 r5:cb75b800 r4:cb75b904
[<bf1cfb04>] (vidioc_streamon+0x0/0x400 [ti81xxvin]) from [<c02d8224>] (__video_do_ioctl+0x164c/0x3fe0)
r6:40045612 r5:00000000 r4:00000001
[<c02d6bd8>] (__video_do_ioctl+0x0/0x3fe0) from [<c02d69c8>] (__video_usercopy+0x2e4/0x428)
[<c02d66e4>] (__video_usercopy+0x0/0x428) from [<c02d6b3c>] (video_ioctl2+0x30/0x38)
[<c02d6b0c>] (video_ioctl2+0x0/0x38) from [<c02d5b7c>] (v4l2_ioctl+0xe8/0x11c)
r5:cc0d6200 r4:cc0c5200
[<c02d5a94>] (v4l2_ioctl+0x0/0x11c) from [<c00d6724>] (vfs_ioctl+0x28/0x44)
r9:c7156000 r8:0001cc70 r7:0000001b r6:0000001b r5:cc0c5200
r4:00000000
[<c00d66fc>] (vfs_ioctl+0x0/0x44) from [<c00d6e34>] (do_vfs_ioctl+0x500/0x540)
[<c00d6934>] (do_vfs_ioctl+0x0/0x540) from [<c00d6ecc>] (sys_ioctl+0x58/0x7c)
[<c00d6e74>] (sys_ioctl+0x0/0x7c) from [<c0046e00>] (ret_fast_syscall+0x0/0x30)
r8:c0046fa8 r7:00000036 r6:0001cc58 r5:00020500 r4:00126b48
---[ end trace 454b631a921228db ]---
446fe080
allocated outbuf:0x4484f880
allocated outbuf:0x449a1080
allocated outbuf:0x44af2880
allocated outbuf:0x44c44080
allocated outbuf:0x44d95880
allocated outbuf:0x44ee7080
allocated outbuf:0x45038880
allocated outbuf:0x4518a080
allocated outbuf:0x452db880
allocated outbuf:0x4542d080
allocated outbuf:0x4557e880
Pipeline is live and does not need PREROLL ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
kernel BUG at drivers/media/video/ti81xx/ti81xxvin_main.c:842!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c7114000
[00000000] *pgd=8787f031, *pte=00000000, *ppte=00000000
Internal error: Oops: 817 [#1]
last sysfs file: /sys/module/pvrsrvkm/initstate
Modules linked in: bufferclass_ti omaplfb pvrsrvkm tlc59108 ti81xxhdmi ti81xxvin ti81xxvo ti81xxfb vpss tvp7002 syslink ipv6
CPU: 0 Tainted: G W (2.6.37+ #42)
PC is at __bug+0x20/0x2c
LR is at release_console_sem+0x198/0x1ac
pc : [<c004a94c>] lr : [<c007008c>] psr: 20000013
sp : c701fb90 ip : c701fac8 fp : c701fb9c
r10: 00000000 r9 : c701fe08 r8 : c701fe08
r7 : cb75b904 r6 : cc15f600 r5 : cb75b800 r4 : cb780400
r3 : 00000000 r2 : 00000001 r1 : 00008e00 r0 : 00000045
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 10c5387d Table: 87114019 DAC: 00000015
Process gst-launch-0.10 (pid: 1487, stack limit = 0xc701e2e8)
Stack: (0xc701fb90 to 0xc7020000)
fb80: c701fbbc c701fba0 bf1d02e4 c004a938
fba0: cc15f600 20000013 00000000 cb75b904 c701fbe4 c701fbc0 c02e32ac bf1d0240
fbc0: 00000001 cb75b800 c7018540 c701fe08 bf1d1524 c701fe08 c701fc4c c701fbe8
fbe0: bf1d002c c02e2f3c 43737000 00000004 00000001 00000000 00000000 00000000
fc00: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000002
fc20: 446fe080 00000000 00000000 00000000 bf1cff94 c044560f c044560f cc0d6200
fc40: c701fdf4 c701fc50 c02d7f60 bf1cffa0 53555f54 54524f48 50004e34 52535256
fc60: 52455f56 5f524f52 41564e49 5f44494c 49564544 44494543 33697500 76654432
fc80: 49656369 56500044 56525352 4655425f 43524546 5353414c 5245505f 544e4f43
fca0: 5f545845 4f464e49 4741545f 52565000 c7036080 00000101 00000000 00000101
fcc0: 00000024 00000001 c701fce4 c701fcd8 c0540cd0 c70402fc 5dd00028 00000001
fce0: c70402f8 00000000 c701fd1c c701fcf8 c006bec8 c01d70f4 c7040304 c7040000
fd00: c0540c88 00000001 c7040030 0017d438 cca77340 c7040030 cca77370 c0540c88
fd20: cca77340 c7040030 c701fd5c c701fd38 c006ba10 c0069e1c c0540c88 c03e1968
fd40: cca77340 cca77340 00000000 00000000 fffffffd 00000000 c701fd8c c701fd68
fd60: c03dd00c c00421c4 c704601c cca77340 00000015 c044560f cc0c5200 c7018540
fd80: c701fda4 c701fd90 c03dd06c c03dcfe4 00000000 c701fda0 c701fdbc c701fda8
fda0: c03dd094 c03dd05c ccbcd000 cca77340 c701fde4 c701fdc0 c03d97a4 c006d260
fdc0: c701e000 7fffffff d5e4a010 00000044 00000000 c044560f 00000000 00000000
fde0: 00000000 c701fe08 c701feb4 c701fdf8 c02d69c8 c02d6be4 c02d6bd8 0017e998
fe00: cc0c5200 00000003 00000004 00000001 00000000 00000000 00000000 00000000
fe20: 00000000 00000000 00000000 00000000 00000000 00000000 00000002 446fe080
fe40: 00000000 00000000 00000000 c701fe58 bf0745c8 bf0729b4 bf074668 bf072900
fe60: c701fea4 d0b2f000 00000000 d5c05700 c701fea4 c701fe80 bf081748 bf072900
fe80: 00000000 c018f361 412d4d60 cc0c5200 0017e998 bf1d2408 c044560f 0017e998
fea0: c701e000 00000000 c701fecc c701feb8 c02d6b3c c02d66f0 cc0c5200 cc0d6200
fec0: c701fef4 c701fed0 c02d5b7c c02d6b18 00000000 cc0c5200 0000001c 0000001c
fee0: 0017e998 c701e000 c701ff04 c701fef8 c00d6724 c02d5aa0 c701ff74 c701ff08
ff00: c00d6e34 c00d6708 0b460d1c 00000067 0b460d1c 00000067 0b460d1c 00000067
ff20: 0000034c c052c9a0 00000000 00000000 00000043 003d0f00 c701e000 00000000
ff40: c701ff5c c701ff50 00000001 00000000 0017e998 c044560f 0000001c cc0c5200
ff60: c701e000 00000000 c701ffa4 c701ff78 c00d6ecc c00d6940 c701ff94 00000001
ff80: c00749d8 00000004 0000034c 405f08d4 00000036 c0046fa8 00000000 c701ffa8
ffa0: c0046e00 c00d6e80 00000004 0000034c 0000001c c044560f 0017e998 446fe080
ffc0: 00000004 0000034c 405f08d4 00000036 00126b48 beeb6d70 0000034c 412d4c2c
ffe0: 0017e940 412d4a70 405d52e8 4052daec 60000010 0000001c 5f535041 45474150
Backtrace:
[<c004a92c>] (__bug+0x0/0x2c) from [<bf1d02e4>] (ti81xxvin_buffer_queue+0xb0/0xe8 [ti81xxvin])
[<bf1d0234>] (ti81xxvin_buffer_queue+0x0/0xe8 [ti81xxvin]) from [<c02e32ac>] (videobuf_qbuf+0x37c/0x43c)
r7:cb75b904 r6:00000000 r5:20000013 r4:cc15f600
[<c02e2f30>] (videobuf_qbuf+0x0/0x43c) from [<bf1d002c>] (vidioc_qbuf+0x98/0xb4 [ti81xxvin])
r9:c701fe08 r8:bf1d1524 r7:c701fe08 r6:c7018540 r5:cb75b800
r4:00000001
[<bf1cff94>] (vidioc_qbuf+0x0/0xb4 [ti81xxvin]) from [<c02d7f60>] (__video_do_ioctl+0x1388/0x3fe0)
r7:cc0d6200 r6:c044560f r5:c044560f r4:bf1cff94
[<c02d6bd8>] (__video_do_ioctl+0x0/0x3fe0) from [<c02d69c8>] (__video_usercopy+0x2e4/0x428)
[<c02d66e4>] (__video_usercopy+0x0/0x428) from [<c02d6b3c>] (video_ioctl2+0x30/0x38)
[<c02d6b0c>] (video_ioctl2+0x0/0x38) from [<c02d5b7c>] (v4l2_ioctl+0xe8/0x11c)
r5:cc0d6200 r4:cc0c5200
[<c02d5a94>] (v4l2_ioctl+0x0/0x11c) from [<c00d6724>] (vfs_ioctl+0x28/0x44)
r9:c701e000 r8:0017e998 r7:0000001c r6:0000001c r5:cc0c5200
r4:00000000
[<c00d66fc>] (vfs_ioctl+0x0/0x44) from [<c00d6e34>] (do_vfs_ioctl+0x500/0x540)
[<c00d6934>] (do_vfs_ioctl+0x0/0x540) from [<c00d6ecc>] (sys_ioctl+0x58/0x7c)
[<c00d6e74>] (sys_ioctl+0x0/0x7c) from [<c0046e00>] (ret_fast_syscall+0x0/0x30)
r8:c0046fa8 r7:00000036 r6:405f08d4 r5:0000034c r4:00000004
Code: e1a01000 e59f000c eb0e39c7 e3a03000 (e5833000)
---[ end trace 454b631a921228dc ]---
ti81xxvin: list empty

  • So I turned on some debugging in the kernel and it looks like there are multiple kernel threads trying to talk to the M4 processor at the same time (there is a queue and dequeue call to teh notify_send_event that happen concurrently, and the second call is stomping the first one).

    Poking around on the arago site, it seems like this patch (below) may fix the issue???   Should we be tracking this git branch for fixes?

    http://arago-project.org/git/projects/?p=linux-dvr-rdk-dm81xx.git;a=commit;h=1907c61b792d688f1e45145e40a2113ce681f231

    -Mike

  • So tried to pull in the recent patches ongoing on the arago site, but the drivers for the firmware (VPSS) are requiring an update version of the firmware.  Any chance someone could make that available?

    Thanks

    -Mike

  • I decided to take a gamble and back off the required firmware version of the VPSS in the fvid2.c file to the one delivered in the most recent EZSDK, and the performance is much more stable now, so those patches seem to be very critical for any sort of gstreamer based preview using the DM8148 EVM.

    However, the gstreamer pipeline does not appear to clean up nicely, and I can only run one capture (see below).  Any insight?

    -Mike

    E.G.:

    root@dm814x-evm:~# gst-launch v4l2src device="/dev/video0" always-copy=false que
    ue-size=16 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1280,height=720,
    framerate=(fraction)60/1' ! omxbufferalloc numBuffers=16 ! omx_scaler ! video/x-
    raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE_720P_60 display
    -device=LCD ! gstperf ! omx_videosink sync=true display-device=LCD preroll-queue
    -len=5 display-mode=OMX_DC_MODE_720P_60
    Mode set is 720P60
    allocating 16 buffers of size:1382400!!
    allocated outbuf:0x44200080
    allocated outbuf:0x44351880
    allocated outbuf:0x444a3080
    allocated outbuf:0x445f4880
    allocated outbuf:0x44746080
    allocated outbuf:0x44897880
    allocated outbuf:0x449e9080
    allocated outbuf:0x44b3a880
    allocated outbuf:0x44c8c080
    allocated outbuf:0x44ddd880
    allocated outbuf:0x44f2f080
    allocated outbuf:0x45080880
    allocated outbuf:0x451d2080
    allocated outbuf:0x45323880
    allocated outbuf:0x45475080
    allocated outbuf:0x455c6880
    Pipeline is live and does not need PREROLL ...
    Setting pipeline to PLAYING ...
    New clock: GstSystemClock
    perf0: frames: 60 current: 59.55 average: 59.55 arm-load: 14
    perf0: frames: 121 current: 60.24 average: 59.90 arm-load: 11
    perf0: frames: 182 current: 60.25 average: 60.01 arm-load: 15
    perf0: frames: 243 current: 60.23 average: 60.07 arm-load: 10
    perf0: frames: 304 current: 60.28 average: 60.11 arm-load: 14
    perf0: frames: 365 current: 60.29 average: 60.14 arm-load: 14
    ...
    Interrupt: Stopping pipeline ...
    Execution ended after 154072775500 ns.
    Setting pipeline to PAUSED ...
    Setting pipeline to READY ...
    Setting pipeline to NULL ...
    Freeing pipeline ...
    gst-launch-0.10: OmxRpcStub.c:1432: OmxRpc_stubGetState: Assertion `(1 == OmxRpc_module->localCoreRcmServer.initDone)' failed.
    Aborted
    root@dm814x-evm:~# gst-launch v4l2src device="/dev/video0" always-copy=false que
    ue-size=16 ! 'video/x-raw-yuv-strided,format=(fourcc)NV12,width=1280,height=720,
    framerate=(fraction)60/1' ! omxbufferalloc numBuffers=16 ! omx_scaler ! video/x-
    raw-yuv,width=800,height=480 ! omx_ctrl display-mode=OMX_DC_MODE_720P_60 display
    -device=LCD ! gstperf ! omx_videosink sync=true display-device=LCD preroll-queue
    -len=5 display-mode=OMX_DC_MODE_720P_60
    Assertion at Line no: 419 in /export/space/ti-ezsdk_dm814x-evm_5_04_00_11/component-sources/syslink_2_10_03_20/packages/ti/syslink/utils/hlos/knl/Linux/../../../../../../ti/syslink/ipc/hlos/knl/Linux/MessageQDrv.c: (cargs.args.create.handle != NULL) : failed
    gst-launch-0.10: OmxRpc.c:624: OmxRpc_Instance_init: Assertion `(OmxRpc_errorNone == retVal)' failed.
    Aborted
    root@dm814x-evm:~#
  • Hi,

    This is a know problem with V4L2. Please look at below thread and apply patches on top of 04.04.00.01 kernel.

  • Hi,

    I think you may have forgot to add a link to the thread?

    -Mike

  • Hi Hardik,

    Thank you for your attention.

    I've already applied those patches (I mentioned this in this thread, actually,  I stumbled on these patches in the arago git tree earlier).  I can successfully capture *once* at 1080p60 or 720p60 (hours at a time), but when I shut the pipeline down I cannot start another one without rebooting the EVM.  The errors from that are included in the second or third post of this thread.   There was a similar post reporting the same problem (link below) that hasn't been answered yet.   The problem seems to be in the omx library, I think it is not shutting down properly when used by the gstreamer / omx API.  Perhaps a race condition between threads (one shutting down the resource, another still querying it)? 

    http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/p/214305/760125.aspx#760125

    Are you able to start and stop capture pipelines more than once without this error using the gstreamer framework?

    -Mike

  • Hi,

    This seems to be a problem with Gstreamer. You can try running saLoopBack application which is present as a part of PSP release package. That runs multiple times.