DRA71XEVM: gstreamer rtsp pipeline does not create output window on waylandsink

Hi Janardhan,

Both the logs don't give enough information.

Can you run each pipeline again with --gst-debug=4 argument added and then share the logs again?

Also let me know which SDK is being used? PSDKLA or visionSDK and the version of the SDK.

Thanks

Ram

Hi Ram,

Thank you for quick reply.

Attached are the logs with debug information.

In the failure log I see "unknown SPS", "skipping until the next keyframe". Looks like all the frames are skipped.

Interestingly the same RTSP URL seems to create output window with playbin,

gst-launch-1.0 -v --gst-debug=4 playbin uri=rtsp://192.168.1.11/stream1 latency=0 protocols=udp video-sink="waylandsink disp-width=1280 disp-height=720"

I'm using PROCESSOR-SDK-LINUX-AUTOMOTIVE  6_00_00_03 on DRA7XX EVM with LCD touch displaygstreamer_failed_WiFi_cam_debug.loggstream_success_WiFi_cam_playbin_debug.loggstream_success_WiFi_cam_playbin_debug.log 

Regards,

Jana 

Hi Janardhan,

The error indicates that the stream received at the decoder end doesn't have the proper header (SPS and PPS) and stream may be corrupted.

As this is happening for the first key frame itself, decoder is not gettinig initialized and no decoder output till next valid key frame comes.

Can you dump the input which is going to decoder?

You can use this pipeline 

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 ! queue ! rtph264depay ! h264parse ! filesink location=dump.h264

Thanks

Ram

Hi Ram,

Attached is the H.264 dump.

I also got wireshark log which shows RTSP Describe reply SDP with correct SPS and PPS.

Packet #15, sprop-parameter-sets=Z01AKI2NQDwBE/LgLcBAQFAAAD6AAA6mDoYAPQgAAX14LvLjQwAehAAAvrwXeXCg,aO44gA==

The same camera works on Ubuntu PC with below pipeline,

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! videoscale ! video/x-raw,width=1920,height=1080 ! autovideosink

This is not camera problem. Something to do with "h264parse" or "ducatih264dec" on PSDKLA.

dump_2.h264.zip

pkt-log.pcap.zip

gstream_success_WiFi_cam_ubuntu_debug.log

Regards,

Jana

Ubuntu PC is running 16.04, kernel 4.15, gst-launch-1.0 version 1.8.3

PSDKLA kernel 4.19, gst-launch-1.0 version 1.14.4. Do you suspect a problem with latest version?

Regards,

Jana

Hi Jana,

I analysed the dump. This doesn't seem to a h264 stream hence ducati decoder is failing to decode.

Do you see this usecse working anytime earlier?

Can you try with software decoder instead of ducati?

Thanks

Ram

Hi Ram,

When I add "config-interval=-1" to h264parse, video rendering starts but I see several frames dropped with errors "<vpebufferpool1> alloc function failed".

modified pipeline,

gst-launch-1.0 -v --gst-debug=4 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse config-interval=-1 ! ducatih264decvpe ! 'video/x-raw, width=(int)1024, height=(int)720' ! queue max-size-buffers=2 ! waylandsink

Debug log gstreamer_WiFi_cam_h264_config_interval_debug.log

I tried to use software decoder with below pipeline, it always does core dump.

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! videoscale ! 'video/x-raw,width=1280,height=960' ! waylandsink

Regards,

Jana

gst-launch-1.0 -v rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! videoscale ! 'video/x-raw,width=1280,height=960' ! waylandsink use-drm=true

Thanks Ram.

I'll test this and get back on the software decoder.

Meanwhile could you investigate "<vpebufferpool1> alloc function failed" errors with Ducati?

We need Ducati hardware decoder for a customer demo and business decision.

Regards,

Jana

Software decoder still does core dump with use-drm=true

gstreamer_WiFi_cam_SW_decode_dump_debug.log

Regards,

Jana

Hi Ram,

Video stream is mostly playing ok with below pipeline without debug logs enabled,

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse config-interval=-1 ! ducatih264dec ! queue ! vpe ! 'video/x-raw, width=(int)1280, height=(int)770' ! queue ! waylandsink

Recorded video clip:

20200626_170128.mp4.tar.gz 

Looks like there is an error in ducati after every 26 frames,

0:00:17.267226357 2256 0x1b1b50 WARN ducati gstducatividdec.c:570:codec_process:<ducatih264dec0> err=-1, extendedError=00000401
0:00:17.267306715 2256 0x1b1b50 ERROR ducati gstducati.c:61:gst_ducati_log_extended_error_info: Bit 0 (00000001): no error-free slice
0:00:17.267345104 2256 0x1b1b50 ERROR ducati gstducati.c:61:gst_ducati_log_extended_error_info: Bit 10 (00000400): insufficient data
0:00:17.271446256 2256 0x1b1b50 WARN ducati gstducatividdec.c:570:codec_process:<ducatih264dec0> err=-1, extendedError=00040000
0:00:17.271489037 2256 0x1b1b50 ERROR ducati gstducati.c:61:gst_ducati_log_extended_error_info: Bit 18 (00040000): stream end

camera is streaming at 30fps. Please investigate the debug log  

gstreamer_WiFi_cam_h264_config_interval_drop_frames_debug_2.log

Thanks,

Jana

Hi Jana,

Good to know that pipeline is working now.

You can ignore the vpe bualloc error. It is always observed with debug enabled.

Now the new error 0x401 means there is a packet loss and decoder is recieving incomplete frame. 

Can you again share the dump of the video stream which is fed to decoder?

I will have a look at the logs and the video clip.

Ram

Hi Jana,

Can you enable logs only for ducati and run the pipeline again and share the logs?

Use this command

export GST_DEBUG=ducati:5

and then run the pipeline, this will show logs only for ducati plugin

Ram

Hi Jana,

I still see the traces "skipping until the next keyframe"  in the log.

This tells the key frames(IDR/I) fed to decoder are erroneous and this make decoder to wait for next key frame, may be every 26th frame is I frame.

This is the reason you are seeing breaks in the observation video.

Ram

Hi Ram,

As I said earlier the same camera stream works well with Ubuntu 16.04 gstreamer pipeline,

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtph264depay ! avdec_h264 ! videoconvert ! videoscale ! video/x-raw,width=1920,height=1080 ! autovideosink

on the DRA7XX EVM we are using h264parse before ducatih264dec is there a way to bypass h264parse? 

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse config-interval=-1 ! ducatih264dec ! queue ! vpe ! 'video/x-raw, width=(int)1280, height=(int)770' ! queue ! waylandsink

I'll provide comparison dumps upto rtph264depay on both Ubuntu 16.04 and DRA7XX EVM.

Meanwhile do you have any other recommendation on what causes the broken stream after ~26frames?

Regards,

Jana 

Attached is the video stream dump after rtph264depay on both Ubuntu 16.04 and DRA7XX EVM.

Beginning and end of the dump is different as I've started and ended recording on different terminals few seconds apart.

Most of the dump data is comparable between Ubuntu 16.04 and DRA7XX EVM means rtph264depay is good on DRA7XX EVM. This proves the issue is with h264parse before ducatih264dec.

dump_rtph264depay_EVM.zip

dump_rtph264depay_ubuntu_laptop.zip

Below is the pipeline I used to dump rtph264depay output,

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 ! queue ! rtph264depay ! filesink location=dump.h264

Regards,

Jana

Here is another test to compare h264parse between Ubuntu 16.04 and DRA7XX EVM.

I installed Intel vaapi hardware decoder and use below pipeline on Ubuntu 16.04,

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse ! vaapidecodebin ! queue ! videoconvert ! videoscale ! video/x-raw,width=1920,height=1080 ! autovideosink

Video stream works fine with this pipeline on Ubuntu 16.04 Intel vaapi hardware decode.

Attached is the video stream dump after h264parse on Ubuntu 16.04.

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse ! filesink location=dump_h264parse_ubuntu.h264

dump_h264parse_ubuntu.h264.zip

I also captured video stream dump after h264parse on DRA7XX EVM.

gst-launch-1.0 rtspsrc location=rtsp://192.168.1.11/stream1 latency=0 protocols=udp ! queue ! rtpjitterbuffer ! rtph264depay ! queue ! h264parse ! filesink location=dump_h264parse_EVM.h264

dump_h264parse_EVM.h264.zip

Beginning and end of the dump is different as I've started and ended recording on different terminals few seconds apart.

Surprisingly most of the h264parse dump data is comparable between Ubuntu 16.04 and DRA7XX EVM. Open question is why vaapidecodebin is able play the stream but not ducatih264dec?

Regards,

Jana

I switched to PSDKLA 5.00.00.01 and do not see this issue. I'll continue to use 5.0 until the issue is resolved on 6.00.00.03.

Thanks,

Jana