<v4l2src0> lost frames detected
Locked
 
|
Hi,
I'm trying to capture MJPG FHD on RP4 at 5fps. It starts fine, however after a while (6-7 mins) getting too many lost frames detected causing downstream elements to starve for buffers. Already increased gpu_mem to 512 MB for rp4. "0:14:31.336100799 500 0x1cc8d50 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 727 - ts: 0:14:30.781242210 0:14:31.384886394 500 0x1cc8d50 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 64 - ts: 0:14:30.829182061 0:14:31.387134673 500 0x1cc8d50 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 38 - ts: 0:14:30.881259209 0:14:31.392512392 500 0x1cc8d50 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 41 - ts: 0:14:30.925273339" I would appreciate any pointers for further debugging. Thanks. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: <v4l2src0> lost frames detected
|
|
Le jeudi 18 juin 2020 à 07:48 -0500, Aniket0987 a écrit :
> Hi, > > I'm trying to capture MJPG FHD on RP4 at 5fps. It starts fine, however after > a while (6-7 mins) getting too many lost frames detected causing downstream > elements to starve for buffers. Already increased gpu_mem to 512 MB for rp4. > "0:14:31.336100799 500 0x1cc8d50 WARN v4l2src > gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = > 727 - ts: 0:14:30.781242210 > 0:14:31.384886394 500 0x1cc8d50 WARN v4l2src > gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = > 64 - ts: 0:14:30.829182061 > 0:14:31.387134673 500 0x1cc8d50 WARN v4l2src > gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = > 38 - ts: 0:14:30.881259209 > 0:14:31.392512392 500 0x1cc8d50 WARN v4l2src > gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = > 41 - ts: 0:14:30.925273339" > > I would appreciate any pointers for further debugging. Thanks. That depends on the pipeline you are using, perhaps you would like to share some more information ? > > > > -- > 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 |
|
|
Hello Nicolas,
Here is my pipeline: v4l2src device=/dev/video0 do-timestamp=true ! image/jpeg,width=1920,height=1080 ! jpegparse ! jpegdec ! video/x-raw,format=I420 ! videorate ! video/x-raw,framerate=5/1 ! videoconvert ! queue leaky=downstream max-size-time=100000000000 ! openh264enc ! h264parse ! out. splitmuxsink name=mp4mux max-size-time=60000000000 max-size-bytes=134217728 location=/tmp/file_ tee name=out ! queue ! mp4mux.video -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: <v4l2src0> lost frames detected
|
|
Le vendredi 19 juin 2020 à 07:54 -0500, Aniket0987 a écrit :
> Hello Nicolas, > > Here is my pipeline: > > v4l2src device=/dev/video0 do-timestamp=true ! Please avoid using do-timestamp property with v4l2src, this will cause drift and could even be the source of your troubles. > image/jpeg,width=1920,height=1080 ! jpegparse ! jpegdec ! You don't need jpegparse here, jpegdec has it's own framing parser. jpegparse is not ranked (hence not autoplugged) as it has many known defects. > video/x-raw,format=I420 ! videorate ! video/x-raw,framerate=5/1 ! For live streams, drop-only property on videorate can improve performance, though it might reduce accuracy. > videoconvert ! queue leaky=downstream max-size-time=100000000000 ! > openh264enc ! h264parse ! out. splitmuxsink name=mp4mux As you are using leaky queues, it is quite strange why the v4l2src overrun. That being said, leaky queues is not strictly needed as v4l2src will kindly drop frames for you. > max-size-time=60000000000 max-size-bytes=134217728 location=/tmp/file_ tee > name=out ! queue ! mp4mux.video It could be storage jitter though, as storage will buffer for a while until it absolutely need to write. > > > > > -- > 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 |
|
|
This post was updated on .
Hi Nicolas,
Thanks for the reply. I've tried removing do-timestamp and jpegparse. I've also added drop-only property for videorate. Things are now working fine for 5 fps. No lost frames detected warning and things work fine. However, when I switch to 30 fps. I start getting following after 8-9 minutes. 0:10:02.477399906 2534 0x183ecc0 WARN videodecoder gstvideodecoder.c:4136:_gst_video_decoder_error:<jpegdec0> error: Failed to decode JPEG image 0:10:02.477503386 2534 0x183ecc0 WARN videodecoder gstvideodecoder.c:4138:_gst_video_decoder_error:<jpegdec0> error: Decode error #53: Not a JPEG file: starts with 0x0f 0x34 0:10:02.477808862 2534 0x183ecc0 DEBUG v4l2src gstv4l2src.c:925:gst_v4l2src_create:<v4l2src0> ts: 1:30:18.919096000 now 1:30:18.941779324 delay 0:00:00.022683324 0:10:02.477902305 2534 0x183ecc0 INFO v4l2src gstv4l2src.c:961:gst_v4l2src_create:<v4l2src0> sync to 0:05:04.533330288 out ts 0:10:01.930956297 0:10:02.477975748 2534 0x183ecc0 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 1 - ts: 0:10:01.930956297 And I get internal data stream eventually. Could this be due to removal of jpegparse? -- 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 |
Re: <v4l2src0> lost frames detected
|
|
Le lundi 22 juin 2020 à 12:35 -0500, Aniket0987 a écrit :
> Hi Nicolas, > Thanks for the reply. > I've tried removing do-timestamp and jpegparse. I've also added drop-only > property for videorate. Things are now working fine for 5 fps. No lost > frames detected warning and things work fine. However, when I switch to 30 > fps. I start getting following after 8-9 minutes. > > 0:10:02.477399906 2534 0x183ecc0 WARN videodecoder gstvideodecoder.c:4136:_gst_video_decoder_error:<jpegdec0> error: Failed to > decode JPEG image > 0:10:02.477503386 2534 0x183ecc0 WARN videodecoder gstvideodecoder.c:4138:_gst_video_decoder_error:<jpegdec0> error: Decode error #53: Not a JPEG file: starts with 0x0f 0x34 > 0:10:02.477808862 2534 0x183ecc0 DEBUG v4l2src gstv4l2src.c:925:gst_v4l2src_create:<v4l2src0> ts: 1:30:18.919096000 now 1:30:18.941779324 delay 0:00:00.022683324 > 0:10:02.477902305 2534 0x183ecc0 INFO v4l2src gstv4l2src.c:961:gst_v4l2src_create:<v4l2src0> sync to 0:05:04.533330288 out ts 0:10:01.930956297 > 0:10:02.477975748 2534 0x183ecc0 WARN v4l2src gstv4l2src.c:980:gst_v4l2src_create:<v4l2src0> lost frames detected: count = 1 - ts: 0:10:01.930956297 > > Could this be due to removal of jpegparse? The driver has been giving you a corrupted JPEG. Imho, for compressed image, UVC driver should report the error but not return the corrupted buffer. But eh, drivers have bugs, just like userspace do. Now, let's see if this corrupted buffer is minimally reported by the driver. If it is, v4l2src will produce buffers with the GST_BUFFER_FLAG_CORRUPTED flag set, and that can be dropped using identity. v4l2src ! identity drop-buffer-flags=corrupted ! jpegedec ! ... It's better to drop as jpegdec can be pretty fragile. It won't make the lost frame go away. It's not clear if your camera queue goes full, or if some firmware error happens (corrupted frames) and then the drops are just caused by a HW reset. You would have to investigate at a kernel level at this point. Nicolas _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
|
|
Okay.
Would it be the same if I used v4l2jpegdec? I can see these notions are ineffective if I make HW acceleration using v4l2jpegdec instead of jpegdec. Getting constant lost frame by v4l2src, more than the time I was using jpegdec. -- Sent from: http://gstreamer-devel.966125.n4.nabble.com/ _______________________________________________ gstreamer-devel mailing list [hidden email] https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel |
Re: <v4l2src0> lost frames detected
|
|
Le jeu. 25 juin 2020 17 h 45, Aniket0987 <[hidden email]> a écrit : Okay. Thinking about this, have you tested with 1.17.1 test release, I believe we allocate more v4l2 buffers there.
_______________________________________________ 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 |