v4l2h264dec Raspberry PI
Locked
 
|
Dear all,
I would kindly ask you for a help with my issue. I have RPI3B+, X11, compiled Gstreamer 1.16, KMS driver,no window manager in X11 I am playing test files this way : gst-launch-1.0 -e filesrc location=/home/pi/jellyfish-15-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=4 ! kmssink It works very much ok only in command line, the speed is amazing. My problem is, since kmssink cannot be used in X11 (as far as I know), I am enclosing following pipelines (both with hardware accelerated sinks) ,with comments, which I would like to encapsulate into GTK window in order to have video rendering in GTK window (GstOverlay or Clutter stage): 1) gst-launch-1.0 -e filesrc location=/home/pi/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=4 ! clutterautovideosink ad 1) This pipeline works but is very slow compared to kmssink (I understand X11 could cause some overhead but could it really be so serious?) Anyway, glimagesink is recommended, therefore in X11: 2) export GST_GL_API=opengl gst-launch-1.0 -e filesrc location=/home/pi/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=4 ! glupload ! glimagesink ad). This pipeline shows one image of the desired video hands printing this output: Setting pipeline to PAUSED ... 0:00:03.869568671 817 0x18a6460 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<filesrc0> pad not activated yet Pipeline is PREROLLING ... Got context from element 'sink': gst.gl.GLDisplay=context, gst.gl.GLDisplay=(GstGLDisplay)"\(GstGLDisplayX11\)\ gldisplayx11-0"; 0:00:04.099781284 817 0x18816f0 WARN v4l2 gstv4l2object.c:4194:gst_v4l2_object_probe_caps:<v4l2h264dec0:src> Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Invalid argument 0:00:04.144984350 817 0x18816f0 WARN v4l2videodec gstv4l2videodec.c:810:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency 0:00:04.184819802 817 0x6e73cac0 WARN v4l2bufferpool gstv4l2bufferpool.c:1263:gst_v4l2_buffer_pool_dqbuf:<v4l2h264dec0:pool:src> Driver should never set v4l2_buffer.field to ANY 0:00:04.270274157 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:04.270424732 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:04.270458014 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:04.297981763 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:04.298045150 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:04.298073119 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:05.932123123 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:05.932190884 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. 0:00:05.932218853 817 0x6e73cac0 WARN dmabuf gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. Pipeline is PREROLLED ... Setting pipeline to PLAYING ... Actually, my final goal is to run following pipeline which is a rendering of a RTSP stream: sudo gst-launch-1.0 rtspsrc location="rtsp://10.0.0.2:8555/test" latency=200 ! rtph264depay ! h264parse ! v4l2h264dec capture-io-mode=4 ! videoconvert ! clutterautovideosink Despite the fact I have to run it in superuser mode otherwise I face issues with size of a buffer, this pipeline (not under cluttersink in X11 nor kmssink without X11 )does not show any video image, just this text output: Progress: (request) Sent PLAY request 0:00:01.178897447 1331 0x73e0e430 FIXME rtpjitterbuffer gstrtpjitterbuffer.c:1551:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Unsupported timestamp reference clock 0:00:01.179056041 1331 0x73e0e430 FIXME rtpjitterbuffer gstrtpjitterbuffer.c:1559:gst_jitter_buffer_sink_parse_caps:<rtpjitterbuffer0> Unsupported media clock 0:00:01.183729166 1331 0x703019b0 FIXME basesink gstbasesink.c:3248:gst_base_sink_default_event:<cluttergstvideosink0> stream-start event without group-id. Consider implementing group-id handling in the upstream elements 0:00:01.247296510 1331 0x703019b0 WARN v4l2 gstv4l2object.c:4194:gst_v4l2_object_probe_caps:<v4l2h264dec0:src> Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Invalid argument Caught SIGSEGV #0 0x76b75120 in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x76c89358 in ?? () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0 0:00:12.853157860 1331 0x73e0e430 WARN rtpjitterbuffer rtpjitterbuffer.c:570:calculate_skew: delta - skew: 0:00:11.140496109 too big, reset skew 0:00:12.868475620 1331 0x73e0e430 WARN rtpjitterbuffer rtpjitterbuffer.c:570:calculate_skew: delta - skew: 0:00:10.961291352 too big, reset skew Spinning. Please run 'gdb gst-launch-1.0 1331' to continue debugging, Ctrl-C to quit, or Ctrl-\ to dump core. Do you have any ideas or recommendation or any reasonable sink to use under X11? Thank you very much Best regards, Ivo -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2h264dec Raspberry PI
|
|
Le mer. 15 mai 2019 15 h 25, horai <[hidden email]> a écrit : Dear all, That is really spammy. It's first time someone report hitting this bug. I'll try and make this warning happened once, sorry for that. That being said, there must be a missing system header, since dmabuf sync API should be available on this fairly recent Linux kernel. Would be good to report the missing system header to your packager. This is libgsallocators library from -base. Now, since you see this warning, it means that the dmabuf was mapped to CPU, which also means dmabuf importation to GL failed (no zero copy). As you are running on X11, you need to force EGL to ensure dmabuf importation is even tried. You can try GST_GL_PLATFORM=egl env. You should also try gles2 API instead of opengl, since the GPU is designed for GLES.
Can you catch this in gdb and share the backtrace ? Not that for live playback over v4l, there is a required fix in decoder base class, which is only released in 1.16.
You could also try xvimagesink. I don't know if it's going to use glamour (GL implementation) or something specific for the platform.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Ok, if I understand correctly. You want me to run this pipeline in GDB, ok?
gst-launch-1.0 -e filesrc location=/home/pi/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=4 ! v4l2convert output-io-mode=5 capture-io-mode=4 ! video/x-raw,format=BGRA ! clutterautovideosink I ran: gdb gst-launch-1.0 and then: run -e filesrc location=/home/pi/jellyfish-3-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=4 ! v4l2convert output-io-mode=5 capture-io-mode=4 ! video/x-raw,format=BGRA ! clutterautovideosink From other command line I sent the STOP signal: kill --signal STOP 15873 after the first warrning appeared I ran: bt result this: #0 0x76bf0120 in poll () at ../sysdeps/unix/syscall-template.S:84 #1 0x754000f4 in ?? () from /usr/lib/arm-linux-gnueabihf/libxcb.so.1 I don't think this is what you want, sorry to ask like an idiot, but all this work is just my hobby and I am not a professional, could you point me how to get exactly what you want? Anyway, what dma-buf concerns I build Gstreamer 1.16 myself. I am missing this during the base plugins build :checking for mmap... yes checking linux/dma-buf.h usability... no checking linux/dma-buf.h presence... no checking for linux/dma-buf.h... no I have a testing kernel 4.19.* but I cannot obtain headers easily (this kernel is not in repository therefore no headers present). I downloaded the entire appropriate kernel source code but command: make headers_install does not install headers to proper directory, moreover exporting header path where dma-buf.h is (for ./autogen.sh: export CPPFLAGS="-I/home/pi/linux-2f5a6b906ad86ef6570863a75b204551c2c62fec/include/linux -I/home/pi/linux-2f5a6b906ad86ef6570863a75b204551c2c62fec/include/uapi/linux" Does not help either -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2h264dec Raspberry PI
|
|
Le jeu. 16 mai 2019 14 h 55, horai <[hidden email]> a écrit : Ok, if I understand correctly. You want me to run this pipeline in GDB, ok? In your log I saw a crash (sigsev), I was curious to find why, it should have stopped by itself on that.
The .h itself have no effect, you have to rebuild gst-plugins-good. That being said, I'm not sure your strictly need it. Another option, if you don't mind runners as root, is to use kmssink on top of X. I cannot tell though if it will just work or if you need plane parameters. It's quite low level.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Hello,
This is a backtrace of following pipeline, the stream is feeded from gst-rtsp-server: gst-launch- 1.0 e -vvv rtspsrc location="rtsp://10.0.0.2:8555/test" latency=200 ! rtph264depay ! h264parse ! v4l2h264dec capture-io-mode=4 ! clutterautovideosink Thread 15 "rtpjitterbuffer" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x6a2fe470 (LWP 23488)] 0x75f807d0 in gst_v4l2_buffer_pool_orphan (bpool=0x121614) at gstv4l2bufferpool.c:982 982 if (!GST_V4L2_ALLOCATOR_CAN_ORPHAN_BUFS (pool->vallocator)) (gdb) bt #0 0x75f807d0 in gst_v4l2_buffer_pool_orphan (bpool=0x121614) at gstv4l2bufferpool.c:982 #1 0x75f942d8 in gst_v4l2_video_dec_set_format (decoder=0x114170, state=0x6f227f00) at gstv4l2videodec.c:249 #2 0x7621c6ec in gst_video_decoder_setcaps (decoder=0x114170, caps=0x6ab18228) at gstvideodecoder.c:712 #3 0x7621dc28 in gst_video_decoder_sink_event_default (decoder=0x114170, event=0x6ab1a0c0) at gstvideodecoder.c:1101 #4 0x75f96ad4 in gst_v4l2_video_dec_sink_event (decoder=0x114170, event=0x6ab1a0c0) at gstv4l2videodec.c:887 #5 0x7621eaf0 in gst_video_decoder_sink_event (pad=0x104650, parent=0x114170, event=0x6ab1a0c0) at gstvideodecoder.c:1367 #6 0x76ed7e18 in gst_pad_send_event_unchecked (pad=0x104650, event=0x6ab1a0c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5765 #7 0x76ed6630 in gst_pad_push_event_unchecked (pad=0x1044f8, event=0x6ab1a0c0, type=GST_PAD_PROBE_TYPE_EVENT_DOWNSTREAM) at gstpad.c:5410 #8 0x76ed0284 in push_sticky (pad=0x1044f8, ev=0x6a2fcb58, user_data=0x6a2fcb98) at gstpad.c:3926 #9 0x76ec3fec in events_foreach (pad=0x1044f8, func=0x76ed0140 <push_sticky>, user_data=0x6a2fcb98) at gstpad.c:608 #10 0x76ed0718 in check_sticky (pad=0x1044f8, event=0x6ab1a0c0) -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Nicolas Dufresne-5
If it is not correct, just give me a hint and I will do what is necessary.
Anyway, I rebuild gstreamer-plugin-base as well as gtreamer-plugin-good with kernel header of 4.19.* in the system. Now it was compiled with dma-buf.h included and the following message is gone: gstdmabuf.c:93:gst_dmabuf_mem_unmap:<dmabufallocator2> Using DMABuf without synchronization. Anyway, the following warning is still present: pi@raspberrypi:~ $ ./playFile Setting pipeline to PAUSED ... 0:00:01.449266020 23614 0x1feda80 WARN basesrc gstbasesrc.c:3600:gst_base_src_start_complete:<filesrc0> pad not activated yet Pipeline is PREROLLING ... 0:00:01.457391198 23614 0x1de5320 WARN v4l2 gstv4l2object.c:4194:gst_v4l2_object_probe_caps:<v4l2h264dec0:src> Failed to probe pixel aspect ratio with VIDIOC_CROPCAP: Invalid argument 0:00:01.468336190 23614 0x1de5320 WARN v4l2videodec gstv4l2videodec.c:810:gst_v4l2_video_dec_decide_allocation:<v4l2h264dec0> Duration invalid, not setting latency 0:00:01.477499274 23614 0x1de5320 WARN v4l2bufferpool gstv4l2bufferpool.c:807:gst_v4l2_buffer_pool_start:<v4l2h264dec0:pool:src> Uncertain or not enough buffers, enabling copy threshold 0:00:01.508788331 23614 0x6f313830 WARN v4l2bufferpool gstv4l2bufferpool.c:1263:gst_v4l2_buffer_pool_dqbuf:<v4l2h264dec0:pool:src> Driver should never set v4l2_buffer.field to ANY -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Nicolas Dufresne-5
Moreover kmssink does not work under X11 no matter if I run it under su or
regular user. My goal is to run rtsp stream on top of X11 just to get GTK support to control stream via buttons, kmssink is super fast, but it runs in command line, maybe there is a way how to build GTK in command line, but I guess creating GUI in X11 is far more As far as I understand from the following forum, running anyting on top of X11 brings huge overhead (therefore I was trying to to run Wayland instead of X11 on Raspberry, just to increase video rendering performance): https://www.raspberrypi.org/forums/viewtopic.php?t=240274 Well, all in all, my focus was narrowed to run glimagesink on top of X11 together with v4l2h264 codecs to get the best performance. So far, I am still having the best results utilizing cluttersink with omxh264dec. Once more, if you have any suggestions or you find something totally wrong or missing some point in what am I writing, please feel free to give any comment as there are tons of things I have to prepare before running beforementioned pipelines on Raspbian (compiling MESA, compiling Gstremer, running testing kernel with headers) so there is a high chance I missed or set up something inapproperietly like dma-buf.h. Thank you -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2h264dec Raspberry PI
|
|
In reply to this post by horai
Le sam. 18 mai 2019 04 h 56, horai <[hidden email]> a écrit : Hello, Thanks, that's really what I was looking for. I suspect the vallocator (v4l2 allocator) pointer is NULL here, hence the crash. This orphaning code is brand new, so that looks like a regression. You may file a bug report, otherwise I will do. I don't have a recent PI at hand, but I suspect I will be able to reproduce this on other device. (gdb) bt _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2h264dec Raspberry PI
|
|
In reply to this post by horai
Le sam. 18 mai 2019 05 h 10, horai <[hidden email]> a écrit : If it is not correct, just give me a hint and I will do what is necessary. This one can be ignored. It's really minor, the driver should have returned ENOTTY instead of EINVAL, but the outcome is the same. This is normally to read back the pixel aspect ratio, but the video parsers does that for us already. 0:00:01.468336190 23614 0x1de5320 WARN v4l2videodec This one should be fixed, should be info, and should say that framerate is not set (duration is calculated from it). 0:00:01.477499274 23614 0x1de5320 WARN v4l2bufferpool That one means that clutter sink didn't fully replied to the allocation query. This warning is valid, because you may end up with a image copies, that would cause jitter. Clutter sink is a bit unmaintained. What I'm thinking now is that you're options are limited on the PI at the moment. I'd try and get glimagesink working, and would use GstVideoOverlay to embed it in your application. To check if dmabuf upload is working, use the following log level: GST_DEBUG=glupload:7
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Ok, I filed a bug here:
https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/issues/609 Hopefully they will understand. Actually, I tried to run the following pipeline with v4l2h264dec in Wayland, but with Gstreamer 1.14: gst-launch-1.0 -e filesrc location=/home/pi/jellyfish-15-mbps-hd-h264.mkv ! matroskademux ! h264parse ! v4l2h264dec capture-io-mode=dmabuf ! waylandsink It is much faster than anything else in X11 (I was not able to fix glimagesink in 1.16), but I am facing a lot of following warnings: 0:00:18.246613271 857 0x74213550 WARN waylandsink wlvideoformat.c: 137:gst_video_format_to_wl_dmabuf_format: wayland dmabuf video format not found Would you be please so kind and give me a hint how to remove this warning and take advantage of dma fully? I guess the dma is not used in this case as it consumes a lot of CPU power. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
In reply to this post by Nicolas Dufresne-5
Actually, I also wanted to try v4l2sink, but I am missing /dev/video1 device,
I only have /dev/video10,11,12 which I assume to be related to v4l2 stuff. I also don't have v4l2convert or v4l2videoconvert present in my 1.14 installation and I am wondering why as I did not see any problem during the ./autogen.sh process of gst-plugins-good. I am trying to get v4l2convert as on this webpage: https://www.raspberrypi.org/forums/viewtopic.php?f=67&t=240274&sid=05f306767626911ef22298fd326579bc They recommend to give kernel switch disable_bayer=1 to reduce the overhead a bit. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2h264dec Raspberry PI
|
|
In reply to this post by horai
Le lun. 20 mai 2019 14 h 10, horai <[hidden email]> a écrit : Ok, I filed a bug here: They means me in this case, I'll try and make a patch for this soon. I haven't used a RPi recently, can you point me to some links on which distro I should flash ? That's only in case I can't reproduce on IMX.6 or DB410c.
Was this one once per stream or spammy (every frame) ? I can also fix this one to be once. In this case, it means your compositor does not advertise the format to be supported using dmabuf, but waylandsink is smart and will use the dmabuf FD to pass the buffer to the compositor without copy. The compositor still need to use slow GL upload, but since it has nothing else to do, it's likely smoother.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
I prefer Raspbian:
https://www.raspberrypi.org/downloads/raspbian/ The warning is not every frame but it appears multiple times, I don't find it annoying. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
«
Return to GStreamer-devel
|
1 view|%1 views
| Free forum by Nabble | Edit this page |