After updating to HailoRT 4.17, I encountered an error when running a GStreamer pipeline that previously worked on HailoRT 4.16.
In HailoRT 4.17 (and the new TAPPAS 3.28), the implementation of the hailonet plugin has been updated to work with the async API. Note that in the previous release, it was referred to as “hailonet2.”
TLDR: To revert to the previous behavior, add ‘force-writable=true’ to the hailonet parameters.
Detailed Explanation:
This plugin is designed to utilize zero-copy on the GStreamer buffer. If the buffer’s reference count is 1, the plugin can add metadata to the buffer without needing to copy it. However, if the buffer is used by more than one element, making it writable might cause a copy.
Refer to the force-writable property in the hailonet description:
gst-inspect-1.0 hailonet ....
force-writable : Controls whether the element will force the input buffer to be writable. We force the inpu
t to be writable with the function gst_buffer_make_writable, which in most cases will do a shallow copy of the buf
fer. But in some cases (when the buffer is marked as not shared - see gst_buffer_copy documentation), it will do a
deep copy.By default, the hailonet element will not force the input buffer to be writable and will raise an error
when the buffer is read-only.
flags: readable, writable
Boolean. Default: false
In cases where you have pipelines with multiple branches, such as ‘tee’ + ‘hmux’, if the buffer is not copied in the hailonet branch (due to ‘videoscale’ or ‘videoconvert’, for example), hailonet will fail to write the metadata to the buffer. Because elements in both branches hold reference to it.
To allow hailonet to make the buffer writable, add the ‘force-writable’ flag to hailonet.
This is not set as default to alert the user that a copy might take place.