v4l2src lost frames on raspberrypi zero wifi
Locked
 
|
Hi all
Gstreamer version: 1.14.2 My device info: v4l2-ctl --list-formats ioctl: VIDIOC_ENUM_FMT Index : 0 Type : Video Capture Pixel Format: 'YUYV' Name : YUYV 4:2:2 Index : 1 Type : Video Capture Pixel Format: 'MJPG' (compressed) Name : Motion-JPEG Raspberry zero wifi as a server side: runing: GST_DEBUG=3 test-launch "( v4l2src ! image/jpeg ! jpegdec ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )" Ubuntu 16.04 as a client side: runing: gst-launch-1.0 rtspsrc location="rtsp://rasp-ip:8554/test" latency=0 ! rtph264depay ! decodebin ! videoconvert ! ximagesink The server side show the following: -------------------------------------------------------------------------------------- root@raspberrypi0-wifi:~# GST_DEBUG=3 test-launch "( v4l2src ! image/jpeg ! jpegdec ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )" stream ready at rtsp://127.0.0.1:8554/test 0:01:30.683202000 305 0xb4e0ee90 FIXME videodecoder gstvideodecoder.c:933:gst_video_decoder_drain_out:<jpegdec0> Sub-class should implement drain() 0:01:30.718953000 305 0xb4e0ee90 WARN v4l2bufferpool gstv4l2bufferpool.c:790:gst_v4l2_buffer_pool_start:<v4l2src0:pool:src> Uncertain or not enough buffers, enabling copy threshold 0:01:31.065635000 305 0xb4e0ee90 FIXME videodecoder gstvideodecoder.c:933:gst_video_decoder_drain_out:<jpegdec0> Sub-class should implement drain() 0:01:32.019512000 305 0x1ba0290 FIXME rtspmedia rtsp-media.c:3835:gst_rtsp_media_suspend: suspend for dynamic pipelines needs fixing 0:01:32.035965000 305 0x1ba0290 FIXME rtspmedia rtsp-media.c:3835:gst_rtsp_media_suspend: suspend for dynamic pipelines needs fixing 0:01:32.038393000 305 0x1ba0290 WARN rtspmedia rtsp-media.c:3861:gst_rtsp_media_suspend: media 0xb5c2f1c0 was not prepared 0:01:32.106016000 305 0x1ba0290 FIXME rtspclient rtsp-client.c:1646:handle_play_request:<GstRTSPClient@0x1ca0878> Add support for seek style (null) 0:01:32.109618000 305 0x1ba0290 FIXME rtspmedia rtsp-media.c:2434:gst_rtsp_media_seek_full:<GstRTSPMedia@0xb5c2f1c0> Handle going back to 0 for none live not seekable streams. 0:01:44.798303000 305 0xb4e0ee90 WARN v4l2src gstv4l2src.c:911:gst_v4l2src_create:<v4l2src0> Timestamp does not correlate with any clock, ignoring driver timestamps 0:01:44.800910000 305 0xb4e0ee90 WARN v4l2src gstv4l2src.c:976:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 22 - ts: 0:00:14.088149667 0:01:48.783236000 305 0xb4e0ee90 WARN v4l2src gstv4l2src.c:976:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 59 - ts: 0:00:18.072994667 0:01:50.959261000 305 0xb4e0ee90 WARN v4l2src gstv4l2src.c:976:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 74 - ts: 0:00:20.249009667 -------------------------------------------------------------------------------------- The client side doesn't show any images. If the server on another ubuntu 16.04 machines, the client side can show normally. Why the v4l2src lost frames on raspberry? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src lost frames on raspberrypi zero wifi
|
|
Le 9 oct. 2018 23 h 42, "Dengke Du" <[hidden email]> a écrit : Hi all You are doing capture, software decode, software encode on a single thread, on the slowest PI. You should look forward using raw capture and omxh264enc, or doing directly encoded capture using rpicamsrc.
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On 2018年10月10日 13:40, Nicolas Dufresne
wrote:
Thanks, but my device was USB camera, not raspberrypi camera module, does rpicamsrc working?
_______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src lost frames on raspberrypi zero wifi
|
|
Le mercredi 10 octobre 2018 à 13:53 +0800, Dengke Du a écrit :
> > You are doing capture, software decode, software encode on a single > > thread, on the slowest PI. You should look forward using raw > > capture and omxh264enc, or doing directly encoded capture using > > rpicamsrc. > > Thanks, but my device was USB camera, not raspberrypi camera module, > does rpicamsrc working? Only with Rasperry Pi Camera. Then try the other suggestion, which is to at try and leverage HW decoder/encoder. I don't know if the Pi Zero have multiple core, but you can also introduce queues in the pipeline to distribute the load. You can also reduce the framerate using "v4l2src ! videorate ! image/jpeg,framerate=5/1" to try and accommodate your small CPU. Just run "top" on the side, both on your PC and your Pi, you'll see the massive difference in CPU usage. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
signature.asc (201 bytes) |
|
On 2018年10月10日 21:13, Nicolas Dufresne
wrote:
Le mercredi 10 octobre 2018 à 13:53 +0800, Dengke Du a écrit :You are doing capture, software decode, software encode on a single thread, on the slowest PI. You should look forward using raw capture and omxh264enc, or doing directly encoded capture using rpicamsrc.Thanks, but my device was USB camera, not raspberrypi camera module, does rpicamsrc working?Only with Rasperry Pi Camera. Then try the other suggestion, which is to at try and leverage HW decoder/encoder. I don't know if the Pi Zero have multiple core, but you can also introduce queues in the pipeline to distribute the load. You can also reduce the framerate using "v4l2src ! videorate ! image/jpeg,framerate=5/1" to try and accommodate your small CPU. Just run "top" on the side, both on your PC and your Pi, you'll see the massive difference in CPU usage. I using: ----------------------------------------------------------------------------------------------------- test-launch "( v4l2src ! videorate ! image/jpeg ! jpegdec ! queue ! x264enc tune=zerolatency ! rtph264pay name=pay0 pt=96 )" ----------------------------------------------------------------------------------------------------- on Raspberry pi zero wifi When the client connect to the Raspberry, I use top command show: ----------------------------------------------------------------------------------------------------- 309 root 20 0 102428 34276 9600 S 97.1 9.0 4:56.59 test-launch ----------------------------------------------------------------------------------------------------- The program exhaust almost the cpu. ----------------------------------------------------------------------------------------------------- cat /proc/cpuinfo | grep processor 0 ----------------------------------------------------------------------------------------------------- So using the USB camera on raspberry pi zero wifi was a bad choice. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src lost frames on raspberrypi zero wifi
|
|
On Thu, 11 Oct 2018 09:53:32 +0800
Dengke Du <[hidden email]> wrote: > On 2018年10月10日 21:13, Nicolas Dufresne wrote: [...] > > > You are doing capture, software decode, software encode on a single > > > thread, on the slowest PI. You should look forward using raw > > > capture and omxh264enc, or doing directly encoded capture using > > > rpicamsrc. [...] > So using the USB camera on raspberry pi zero wifi was a bad choice. > As Nicolas already said, try to avoid all the software decoding and encoding. This means: 1. Instead of MJPEG, use raw video from the webcam, it supports it, this removes the need for jpeg decoding. A pixelformat conversion from YUYV to one accepted by the encoder could still be needed but it should be faster than JPEG decoding. (Check if USB bandwidth becomes a problem, tho). 2. Instead of x264enc, which is the element which uses the most CPU, try the hardware accelerated alternatives like omxh264enc, and if it is not available on your installation, look up how to install it and configure it (e.g. GPU RAM settings). The pipeline becomes something like: test-launch "( v4l2src ! video/x-raw ! queue ! videoconvert ! omxh264enc ! rtph264pay name=pay0 pt=96 )" Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
On 2018年10月11日 15:46, Antonio Ospite wrote: > On Thu, 11 Oct 2018 09:53:32 +0800 > Dengke Du <[hidden email]> wrote: > >> On 2018年10月10日 21:13, Nicolas Dufresne wrote: > [...] >>>> You are doing capture, software decode, software encode on a single >>>> thread, on the slowest PI. You should look forward using raw >>>> capture and omxh264enc, or doing directly encoded capture using >>>> rpicamsrc. > [...] >> So using the USB camera on raspberry pi zero wifi was a bad choice. >> > As Nicolas already said, try to avoid all the software decoding and > encoding. > > This means: > > 1. Instead of MJPEG, use raw video from the webcam, it supports it, this > removes the need for jpeg decoding. A pixelformat conversion from > YUYV to one accepted by the encoder could still be needed but it > should be faster than JPEG decoding. (Check if USB bandwidth becomes > a problem, tho). > > 2. Instead of x264enc, which is the element which uses the most CPU, try > the hardware accelerated alternatives like omxh264enc, and if it is > not available on your installation, look up how to install it and > configure it (e.g. GPU RAM settings). > > The pipeline becomes something like: > > test-launch "( v4l2src ! video/x-raw ! queue ! videoconvert ! omxh264enc ! rtph264pay name=pay0 pt=96 )" > > Ciao, > Antonio > video/x-raw ! queue ! videoconvert ! omxh264enc ! rtph264pay name=pay0 pt=96 )" stream ready at rtsp://127.0.0.1:8554/test OMX-Cannot open OpenMAX registry file /home/root/.omxregister OMX-A Component loader constructor fails. Exiting 0:00:03.376066000 369 0xb5c064c0 ERROR omx gstomx.c:162:gst_omx_core_acquire: Failed to initialize core '/usr/lib/libomxil-bellagio.so.0': 0x80001000 0:00:03.378567000 369 0xb5c064c0 WARN videoencoder gstvideoencoder.c:1627:gst_video_encoder_change_state:<omxh264enc-omxh264enc0> error: Failed to open encoder 0:00:03.384602000 369 0xb5c064c0 WARN rtspmedia rtsp-media.c:2970:start_preroll: failed to preroll pipeline 0:00:03.386592000 369 0xb5c064c0 WARN rtspmedia rtsp-media.c:3092:start_prepare: failed to preroll pipeline 0:00:03.388589000 369 0x1b08490 WARN rtspmedia rtsp-media.c:2991:wait_preroll: failed to preroll pipeline 0:00:03.389947000 369 0x1b08490 WARN rtspmedia rtsp-media.c:3295:gst_rtsp_media_prepare: failed to preroll pipeline 0:00:03.399707000 369 0x1b08490 ERROR rtspclient rtsp-client.c:1044:find_media: client 0x1b12088: can't prepare media 0:00:03.410922000 369 0x1b08490 ERROR rtspclient rtsp-client.c:2899:handle_describe_request: client 0x1b12088: no media Maybe something wrong with "/home/root/.omxregister"? _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: v4l2src lost frames on raspberrypi zero wifi
|
|
Le jeu. 11 oct. 2018 04 h 48, Dengke Du <[hidden email]> a écrit :
When you build gst-omx, you need to specify the target, since OMX on RPi is incompatible with anything else (all OMX implementation are in fact incompatible with each other). 0x80001000 _______________________________________________ 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 |