Hi All
I'm using EZSDK_5_05 (NOTE: the problem occurs on 5_04 as well) and the dm8168 processor. We have our own hardware with an FPGA that converts SDI video to BT1120 format that comes into the vin0 port. We've modified the vin drivers to support this configuration and 720p50 video and have the following gstreamer pipe running:
"gst-launch v4l2src device=/dev/video0 always-copy=false queue-size=6 ! video/x-raw-yuv-strided, format=(fourcc)NV12, framerate=(fraction)50/1, width=(int)1280, height=(int)720 ! omxbufferalloc numBuffers=6 ! omx_h264enc profile=8 level=2048 force-idr=true force-idr-period=25 i-period=0 bitrate=12000000 rateControlPreset=0 input-buffers=6 output-buffers=8 ! queue ! rtph264pay ! udpsink host=224.0.1.17 ttl-mc=32 port=5004 -e -v --gst-debug=v4l2src:2"
This pipe continues to run without issues for 5+hours and then suddenly stop without any error messages. Its as if the video source dried up. However, I've managed to force this condition to happen after 30 seconds by supplying a video source thats got a random noise pattern. However, if I remove the "rtph264pay" transport plugin from the pipe it continues running even with the noise pattern and even if I load the processor to 100% with a test app with a while(1) loop. Replacing rtph264pay with mpegtsmux transport stream forces the issue to happen immediately with the noise pattern.
Can anyone please give advice how to pin-point/debug this type of issue, at the momemt I'm not sure is the problem in gstreamer, gstreamer plugins, omx, device drivers or even in the M3 code?
Kind regards
Johan
