GStreamer (nvvidconv): NVMAP_IOC_WRITE failed: Interrupted system call

Hi all,

I have a gstreamer pipeline that I feed from an appsrc and feeds into a display branch. (Please see the attached png, please ignore the fakesink branch


). The appsrc is fed from an USB3 camera with the following pseudocode:

    m_cam.getNextFrame (m_rawImageSize, &m_RawImage[0]); //rawImageSize is computed before. This is a blocking call


    getFormattedImageSize(&m_RawImage[0], IMAGE_FORMAT_TIFF, &m_encodedImageSize);
       /**
         * For some extremely weird reason, the following line of code makes the error
         * "NVMAP_IOC_WRITE failed: Interrupted system call"
         * go away. It is generated by a nvvidconv element in the gstreamer pipeline. The error itself doesn't seem
         * to have any effect on the moviefile it generates, but it is still very strange.
         */
      m_encodedImage = std::vector<char>(m_encodedImageSize);
    
    GstBuffer *buffer;
    GstMapInfo map;
    GstFlowReturn ret;

    buffer = gst_buffer_new_and_alloc(m_rawImageSize);
    gst_buffer_map(buffer, &map, GST_MAP_WRITE);
    memcpy((char *) map.data, &m_RawImage[0], m_rawImageSize);
    gst_buffer_unmap(buffer, &map);

    GST_BUFFER_DURATION(buffer) = gst_util_uint64_scale_int(1, GST_SECOND, 25);
    
    gst_app_src_push_buffer((GstAppSrc *) appsrc, buffer);

In principle this all works fine (the image is displayed correctly), but I still get the

NVMAP_IOC_WRITE failed: Interrupted system call

error thrown at me if I don’t allocate that m_encodedImage vector (see the code). The weird thing is, I don’t use that vector at all anywhere, so I would prefer to ditch it (it’s there from earlier work), but I first want to understand what exactly is happening. I’ve played around with the pipeline and the error is generated by the nvvidconv component sitting before the nvdrmvideosink. Any ideas?

Thanks!

Hi,
Are you able to send buffers in 2448x1378 or 2448x1376 to nvvidconv plugin? Odd resolution may not work properly.

Incredible, thank you! Same error at 1378, but with 1376 it’s gone!