oops in v4l2src when going from pause to play

Thu Jan 24 01:01:48 UTC 2019

Le mercredi 23 janvier 2019 à 16:39 -0600, dwight_g a écrit :
> Using v1.12.5 built on nVidia Jetson TX2, video capture from /dev/video0
> (I've tried with alternate capture sources as well), going to 1.14.4
> difficult at this point due to nvidia specific plugins.
> 
> I'm struggling with a crash in v4l2src that happens when after the pipeline
> stops delivering frames to appsink I switch the pipeline from PLAY to PAUSE
> and back.
> 
> I've used both gst_parse_launch() and normal methods to build the pipeline
> and the only difference it appears to be is the crash will be caught in
> debugger when using gst_parse_launch() vs only showing up in dmesg and
> putting a thread into D (which then I have to reboot the cp to start again).
> Note if I do gst-inspect-1.0 v4l2src at this point it also ends up as D in
> top.
> 
> from dmesg:
> 
> [ 2246.920116] Unable to handle kernel paging request at virtual address
> ffffffc5b4450910
> [ 2246.920129] pgd = ffffffc1bf465000
> [ 2246.920135] [ffffffc5b4450910] *pgd=0000000000000000,
> *pud=0000000000000000
> [ 2246.920147] Internal error: Oops: 96000045 [#1] PREEMPT SMP

I'd say do things in the right order, get the kernel oops to be fixed
first. A kernel oops is always a kernel bug.

> [ 2246.920152] Modules linked in: snd_usb_audio snd_hwdep snd_usbmidi_lib
> fuse iptable_filter ip_tables bcmdhd bluedroid_pm
> [ 2246.920178] CPU: 0 PID: 7275 Comm: v4l2src0:src Not tainted 4.4.38-tegra
> #28
> [ 2246.920184] Hardware name: quill (DT)
> [ 2246.920189] task: ffffffc1e10c6400 ti: ffffffc05601c000 task.ti:
> ffffffc05601c000
> [ 2246.920200] PC is at __vb2_queue_alloc+0x50/0x44c
> [ 2246.920206] LR is at __vb2_queue_alloc+0xfc/0x44c
> [ 2246.920211] pc : [<ffffffc0007b5724>] lr : [<ffffffc0007b57d0>] pstate:
> 60000045
> [ 2246.920215] sp : ffffffc05601faf0
> [ 2246.920220] x29: ffffffc05601faf0 x28: 0000000000000001 
> [ 2246.920228] x27: ffffffc1eb42aa94 x26: ffffffc1eb42aa58 
> [ 2246.920235] x25: 0000000000000002 x24: ffffffc179204800 
> [ 2246.920243] x23: 0000000000000001 x22: 0000000000000001 
> [ 2246.920250] x21: 0000000000000002 x20: ffffffc1eb42a880 
> [ 2246.920256] x19: ffffffc179204800 x18: 0000007f380810d0 
> [ 2246.920263] x17: 0000007fb73d0b20 x16: ffffffc0001e6610 
> [ 2246.920270] x15: 001dcd6500000000 x14: ffffffc000b92a60 
> [ 2246.920276] x13: ffffffc000b92a60 x12: 00000000000000e3 
> [ 2246.920283] x11: 00e80001e1c4778f x10: ffffffc000f9f1c8 
> [ 2246.920289] x9 : ffffffc000f9f1e0 x8 : ffffffc1998aa000 
> [ 2246.920296] x7 : 0000000079204c00 x6 : 00000001e1c47000 
> [ 2246.920303] x5 : ffffffbdc7871300 x4 : 00e80001e1c4770f 
> [ 2246.920309] x3 : 00e800000000070f x2 : ffffffc052176fd0 
> [ 2246.920315] x1 : 0000000000000000 x0 : 0000000079204c12 
> 
> [ 2246.920327] Process v4l2src0:src (pid: 7275, stack limit =
> 0xffffffc05601c020)
> [ 2246.920332] Call trace:
> [ 2246.920338] [<ffffffc0007b5724>] __vb2_queue_alloc+0x50/0x44c
> [ 2246.920345] [<ffffffc0007b6808>] vb2_core_create_bufs+0xe0/0x24c
> [ 2246.920352] [<ffffffc0007b85d4>] vb2_ioctl_create_bufs+0x90/0xb0
> [ 2246.920359] [<ffffffc0007a4db8>] v4l_create_bufs+0x64/0x90
> [ 2246.920365] [<ffffffc0007a3ad8>] __video_do_ioctl+0x22c/0x2a0
> [ 2246.920372] [<ffffffc0007a3538>] video_usercopy+0x254/0x5ac
> [ 2246.920377] [<ffffffc0007a38a4>] video_ioctl2+0x14/0x1c
> [ 2246.920383] [<ffffffc00079e898>] v4l2_ioctl+0xbc/0xcc
> [ 2246.920392] [<ffffffc0001e6350>] do_vfs_ioctl+0x324/0x5e4
> [ 2246.920397] [<ffffffc0001e6694>] SyS_ioctl+0x84/0x98
> [ 2246.920404] [<ffffffc000084ff0>] el0_svc_naked+0x24/0x28
> [ 2246.920604] ---[ end trace c1d8333e79b3cc99 ]---
> 
> 
> 
> 1. I cannot understand why the pipeline stalls and stops delivering frames,
> except with GST_DEBUG=v4l2*:5 I see messages related to buffer pool about
> lost buffers being reallocated at the point it appears to stall. I see it
> occasionally when it does not stall, but at the breaking point there is
> several successive and then it stalls.
> 
> 2. Even if it does stall, what am I missing in order to recover? I assume
> setting pipeline to NULL and releasing then rebuilding the pipeline, but if
> I go from PLAY to NULL I have an exception and crash. I think I'm missing
> fundamental knowledge or something.
> 
> pipeline:
> 
> "v4l2src device=/dev/video0 do-timestamp=true ! video/x-raw, width=1920,
> height=1080, framerate=30/1, format=UYVY ! watchdog timeout=12000 \
> ! tee name=t1 \
>  t1. ! queue name=t1_nvvidconv0_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! nvvidconv ! video/x-raw(memory:NVMM), width=1920,
> height=1080, framerate=30/1, pixel-aspect-ratio=1/1, format=I420 \
> ! tee name=t2 \
>  t2. ! queue name=t2_nvoverlaysink0_queue max-size-buffers=0
> max-size-bytes=0 max-size-time=0 ! nvoverlaysink display-id=1 overlay=1
> overlay-depth=0 enable-last-sample=false \
>  t2. ! queue name=t2_omxh264enc0_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! omxh264enc bitrate=7000000 profile=main control-rate=2
> EnableStringentBitrate=true iframeinterval=15 vbv-size=0 ! video/x-h264,
> level=(string)4.2, stream-format=(string)byte-stream ! h264parse \
> ! multiqueue name=mq  max-size-bytes=0  max-size-time=0  max-size-buffers=0
> sync-by-running-time=true ! mq.sink_0 mq.src_0 ! mpegtsmux name=tsmux !
> rtpmp2tpay ! queue name=udpsink_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! udpsink port=11000 async=false sync=false host=127.0.0.1 \
>  t1. ! queue name=t1_nvvidconv1_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! nvvidconv ! video/x-raw(memory:NVMM), width=648,
> height=364, framerate=30/1, pixel-aspect-ratio=1/1, format=BGRx 
> ! queue name=nvvidconv1_nvvidconv2_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! nvvidconv ! video/x-raw ! queue
> name=nvvidconv2_vidsink_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! appsink name=vidsink enable-last-sample=false \
> alsasrc device=dsnooped ! queue name=alsasrc_queue max-size-buffers=0
> max-size-bytes=0 max-size-time=0 ! audioconvert ! audioresample !
> audio/x-raw,channels=1,channel-mask=(bitmask)0x1 ! queue
> name=alsasrc_i0_queue max-size-buffers=0 max-size-bytes=0 max-size-time=0 !
> i.sink_0 \
> appsrc name=audsrc is-live=true max-bytes=4096 ! audioconvert !
> audioresample ! audio/x-raw,channels=1,channel-mask=(bitmask)0x2 ! queue
> name=audsrc_i1_queue max-size-buffers=0 max-size-bytes=4096 max-size-time=0
> ! i.sink_1 \
> interleave name=i \
> ! tee name=t3 \
>  t3. ! queue name=t3_voaacenc0_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! audioconvert ! audioresample !
> audio/x-raw,channels=2,channel-mask=(bitmask)0x3 ! voaacenc ! aacparse !
> mq.sink_1 mq.src_1 ! tsmux. \
>  t3. ! queue name=t3_alsasink0_queue max-size-buffers=0 max-size-bytes=0
> max-size-time=0 ! audioconvert ! audioresample !
> audio/x-raw,channels=2,channel-mask=(bitmask)0x3 ! alsasink
> device=plughw:0,3 sync=false \
> ";
> 
> 
> I set all queues (except 1) unlimited to see if any were loading up.
> 
> The dot files between gst_parse_lauch() of above and coded pipeline look
> identical after much gnashing of teeth getting everything connected.
> 
> running a similar pipeline via gst-launch-1.0 also stalls - I have gst-shark
> enabled and the log file is 765MB though...gst.launch.txt
> 
> help!?, pointers!?
> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel