Skip to:

  1. Skip to Jira Navigation
  2. Skip to Side Navigation
  3. Skip to Main Content

Waltham-transmitter: DRM error No=6, No=11 and No=24

Fixed

Description

Preparation:

Modify output.c in waltham transmitter as below to get the error number.

Set up the boards:

Waltham-tranmitter (IVI) side:
Execute startup.sh and enable_debug.sh in AMM2019-startup-m3ulcb-vertical-latest.tar.xz 

Waltham-receiver (Cluster) side: 

Execute startup.sh and enable_debug.sh in AMM2019-startup-m3ulcb-horizontal-latest.tar.xz 

make sure you have installed waltham-receiver at Cluster side.

Reproducibility:

Always

Reproduction scenario:

ErrorNo=6: It is shown once (sometimes 3 times) in the below steps, sometimes the errNo was 11 instead of 6.
ErrorNo=24: It is continuously shown 1 minite later after 5. start navigating

  1. Start tbtNavi app

  2. Start receiver

  3. Set the destination on tbtNavi

  4. Start transmitting tbtNavi

  5. tbtNavi can be seen on waltham receiver, Start navigating

 Error logs:

weston-ivi-5078-w_patch-5.log

 

Environment

guppy 7.0.1 Waltham-transmitter: Rcar M3 Waltham-receiver: Rcar M3 (https://gerrit.automotivelinux.org/gerrit/c/src/weston-ivi-plugins/+/21475)

Attachments

3

Activity

Show:

Naoko Tanibata 
August 23, 2019 at 8:24 AM

Hello Aketa san,

Would you verify that the errors are not shown if you update pipeline configuration as above?

Veeresh Kadasani 
July 16, 2019 at 2:44 AM

 We can also use queue element in-between appsrc and videoconvert and use leaky property of queue which will drop the buffer when the queue becomes full in other words if the videoconvert is slower  queue becomes full if not the queue wont get full and there will be no dropping of buffer.

Before Modification pipeline.cfg:

appsrc name=src ! videoconvert ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=34400 sync=false async=false

After Modification pipeline.cfg:

appsrc name=src ! queue leaky=2 ! videoconvert ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=34400 sync=false async=false

Note: leaky value

0 = no leaky but block

1 = drop new buffer

2 = drop old buffer

Veeresh Kadasani 
July 12, 2019 at 8:57 AM

 vspfilter is platform specific element(rcar platform) and it cannot be used for other platform so one more solution is to use n-thread property of videoconvert element which specifies the number of threads to be used when doing conversion

Before Modification pipeline.cfg:

appsrc name=src ! videoconvert ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=34400 sync=false async=false

After Modification pipeline.cfg:

appsrc name=src ! videoconvert n-threads=4 ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=344

Veeresh Kadasani 
July 9, 2019 at 4:18 AM
(edited)

The error(errorno=24 too-many-open-file) occurred because of using videoconvert(colour space conversion and scaling) element which is software based  color conversion element which cannot process at 60 fps and hold the gst_memory till processing is complete and then free the memory which in turn closes the fd.

If we replace the videonconvert with hardware accelerated version of conversion i.e videoconvert → vspfilter(since the conversion happens using hardware, processing is faster) as following on transmitter side this issue is not reproducible.The previous fd is closed before the call drmPrimeHandleToFD to get the new fd.

Before Modification pipeline.cfg:

appsrc name=src ! videoconvert ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=34400 sync=false async=false

After Modification pipeline.cfg:

appsrc name=src max-bytes=0 ! vspfilter ! video/x-raw,format=I420 ! omxh264enc bitrate=3000000 control-rate=2 ! rtph264pay ! udpsink name=sink host=192.168.2.52 port=34400 sync=false async=false

Veeresh Kadasani 
July 5, 2019 at 6:10 AM
(edited)

For every repaint in weston we call transmitter_output_repaint (60 times for 60 fps and 30 times for 30 fps application).

We rely on Gstreamer to close the fd passed to it.

The releasing of the buffer by gstreamer after pushing the buffer in appsrc takes some time and closing of fd also.

When the fd is still not closed by gstreamer (for 60 fps) we get repaint and we call drmPrimeHandleToFD to get new fd.

The rate at which we get new fd is higher than the rate at which gstreamer closes the fd . At certain point(after one minute in our case) we reach max number fd i.e 1024 an application can open and we start getting This error.

Details

Assignee

Reporter

Fix versions

Due date

Priority

Created June 19, 2019 at 1:15 PM
Updated December 12, 2019 at 2:12 AM
Resolved November 13, 2019 at 8:02 AM