This post was updated on .
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 [ 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...gstlog.txt help!?, pointers!? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list gstreamer-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
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 > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
I eventually managed to update to 1.14.4 and after figuring out the existing
nvvidconv fails to allow DMA access when copy-threshold enabled (add io-mode=2 to v4l2src parameters), it immediately failed again with the same error: Looking up I see I left off the 'unable to handle kernel paging request error message' though. Except further digging I realize what Nicolas' point was - though this says 'Process v4l2src0' it appears the crash trace functions are in V4l2 driver...when the v4l2src plugin appears to request buffers while streaming already. I found a couple similar problems reported on RasbPi's... -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le jeudi 24 janvier 2019 à 21:16 -0600, dwight_g a écrit :
> I eventually managed to update to 1.14.4 and after figuring out the existing > nvvidconv fails to allow DMA access when copy-threshold enabled (add > io-mode=2 to v4l2src parameters), it immediately failed again with the same > error: > > > > Looking up I see I left off the 'unable to handle kernel paging request > error message' though. > > Except further digging I realize what Nicolas' point was - though this says > 'Process v4l2src0' it appears the crash trace functions are in V4l2 > driver...when the v4l2src plugin appears to request buffers while streaming > already. I found a couple similar problems reported on RasbPi's... Then disable VIDIOC_CREATE_BUFS support in your driver if it's crashing the kernel. This IOCTL is specially designed fro run-time allocation, and only make sense for drivers using virtual memory. Nicolas > > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Nicolas Dufresne-5 wrote
> Then disable VIDIOC_CREATE_BUFS support in your driver if it's crashing > the kernel. This IOCTL is specially designed fro run-time allocation, > and only make sense for drivers using virtual memory. This is where I show my ignorance, of which driver do you speak? The only place I see VIDIOC_CREATE_BUFS referenced is in v4l2-core..? -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Le vendredi 25 janvier 2019 à 23:27 -0600, dwight_g a écrit :
> Nicolas Dufresne-5 wrote > > Then disable VIDIOC_CREATE_BUFS support in your driver if it's crashing > > the kernel. This IOCTL is specially designed fro run-time allocation, > > and only make sense for drivers using virtual memory. > > This is where I show my ignorance, of which driver do you speak? The only > place I see VIDIOC_CREATE_BUFS referenced is in v4l2-core..? You said GStreamer is allocating more buffer at runtime, and this is the only way userspace could possibly do that with a v4l2 driver. If this ioctl is not implemented in your driver, then GStreamer is not allocating more buffers at run-time. Maybe you driver crashes upon caps renegotiation (which least to a relatively fast streamoff/streamoff sequence). Nicolas > > > > > > -- > Sent from: http://gstreamer-devel.966125.n4.nabble.com/ > _______________________________________________ > gstreamer-devel mailing list > [hidden email] > https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Free forum by Nabble | Edit this page |