RSPI 4 and Cam streaming

[Nicolas Dufresne]

Le mardi 22 septembre 2020 à 07:37 -0500, DejanCotra a écrit :
> Hi Nicolas,
> 
> I finally manage to receive my HW encoded stream (problem was in how I
> started pipeline nothing to do with RSPI4 or gstreamer).
> 
> But I run into another problem Im fighting with this one for some time now
> with no luck.
> 
> From RSPI4 Im streaming camera via webrtc (QT application with Gstremer
> 1.16.2) Im using pipeline:
> *v4l2src ! video/x-raw,width=(int)640,height=(int)480 ! queue ! v4l2h264enc
> ! queue ! video/x-h264 ! h264parse ! rtph264pay ! queue ! " RTP_CAPS_H264
> "96*
> 
> on receiving end its windows 10 application with Java bindings for Gsrteamer
> 1.16.2, it handles incoming video stream with: 
> *queue ! videoconvert ! autovideosink*.
> 
> Stream starts ok. But after 1 to 35 minutes it just freezes. 
> 
> If I use SW encoder and send camera stream like this:
> *v4l2src device=/dev/video0 ! video/x-raw, format=(string)YUY2,
> width=(int)640, height=(int)480 ! videoconvert ! queue ! x264enc bitrate=600
> speed-preset=ultrafast tune=zerolatency key-int-max=15 !
> video/x-h264,profile=constrained-baseline ! h264parse ! rtph264pay
> config-interval=-1 name=payloader ! queue ! " RTP_CAPS_H264 "96 !*
> 
> It runs smoothly for 2h no problem (then I switch it off).
> 
> So only difference is encoder. Do you have any hint?
> 
> Further more I try to with error logs * ( qputenv("GST_DEBUG", "4") )*. No
> errors.
> Aslo I try with * ( qputenv("GST_DEBUG", "v4l2videoenc*:7") )*
> and while streaming is running there are print outs:
> *4l2videoenc gstv4l2videoenc.c:640:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Allocate output buffer
> 4l2videoenc gstv4l2videoenc.c:653:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Process output buffer
> 4l2videoenc
> gstv4l2videoenc.c:718:gst_v4l2_video_enc_handle_frame:<v4l2h264enc0>
> Handling frame 1938
> v4l2videoenc
> gstv4l2videoenc.c:620:gst_v4l2_video_enc_get_oldest_frame:<v4l2h264enc0>
> Oldest frame is 1937 0:01:10.613883808 and 1 frames left
> v4l2videoenc gstv4l2videoenc.c:640:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Allocate output buffer
> v4l2videoenc gstv4l2videoenc.c:653:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Process output buffer
> v4l2videoenc
> gstv4l2videoenc.c:718:gst_v4l2_video_enc_handle_frame:<v4l2h264enc0>
> Handling frame 1939
> v4l2videoenc
> gstv4l2videoenc.c:620:gst_v4l2_video_enc_get_oldest_frame:<v4l2h264enc0>
> Oldest frame is 1938 0:01:10.649288698 and 1 frames left
> v4l2videoenc gstv4l2videoenc.c:640:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Allocate output buffer
> v4l2videoenc gstv4l2videoenc.c:653:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Process output buffer
> v4l2videoenc
> gstv4l2videoenc.c:620:gst_v4l2_video_enc_get_oldest_frame:<v4l2h264enc0>
> Oldest frame is 1939 0:01:10.681470957 and 0 frames left
> v4l2videoenc gstv4l2videoenc.c:640:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Allocate output buffer
> v4l2videoenc gstv4l2videoenc.c:653:gst_v4l2_video_enc_loop:<v4l2h264enc0>
> Process output buffe*
> once stream freezes printouts just stop with no error.

Perhaps follow up with the RPi dev ? You will likely be asked to run
this in a debugger, and create a backtrace at the point it get stuck.
Perhaps keep us CCed, we can try and help root cause this. I have been
running some pipeline on other SoC for few days, so I suspect there is
a driver specific issue here.

> 
> 
> 
> 
> --
> 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