Allocating a GstBuffer of type "memory:NVMM"

@DaneLLL

Thank you. The problem was, indeed, me disregarding pitch. A great prat of that was that I am used to this variable called “stride”, and that I could not find documentation on what those fields mean. Either way, I am now getting correct picture encoded.

Is there any news about the force-IDR crash?

Thank you,
Shachar

Hi,
We apply the change to the sample and don’t observe the segment fault.

gst_element_set_state((GstElement*)gst_pipeline, GST_STATE_PLAYING);
    sleep(5);
    GstFlowReturn ret;
    g_print("signal force-IDR \n");
    g_signal_emit_by_name (G_OBJECT(encoder), "force-IDR", NULL, &ret);
    //g_print("Change bit rate to 4Mbps \n");
    //g_object_set (G_OBJECT(encoder), "bitrate", 4000000, NULL);
    sleep(10);

Please check if it helps by cleaning the cache:

$ rm .cache/gstreamer-1.0/registry.aarch64.bin

Hi @DaneLLL,

First of all, thank you for all of your help.

Unfortunately, with the IDR problem still present, and with metadata not available on GStreamer, I’ve pivoted to using the V4L interface directly.

Despite all of your genuine effort, I have to admit I have found the overall experience to be very disappointing. I also have a latency problem, but I suspect it has to do with the way I’m allocating the buffers (no pool because it’s test code), so probably on my end.

But even without it, I found the documentation to be insufficient, and the examples of poor coverage and confusing. Worse, the API itself does not expose the full power that the underlying API has.

For comparison’s sake, starting from scratch with the V4L interface allowed me to reach the same point in only three days of work, and with zero reliance on NVidia support, because the provided example covers the entire API. I would not call teasing the desired flow from 2000 lines of code “optimal”, but at least it is possible to do.

It seems to me that GStreamer is hailed as the front-door way of using the encoder, but it is simply not up to the task.

I honestly do appreciate your help.
Shachar

Hi,
Could you re-flash the system through SDLManager and try again? Since we don’t observe the segment fault, probably the system is not clean and it might help to do clean re-flash.

Please enable the property to get run hardware encoder in max performance:

  maxperf-enable      : Enable or Disable Max Performance mode
                        flags: readable, writable, changeable only in NULL or READY state
                        Boolean. Default: false

And execute sudo jetson_clocks to run system in maxper formance. To get system loading in runtime, you can execute sudo tegrastats.

We have sample pipelines in gstreamer documemnt. For your reference, though the examples may not fit your usecase.

BTW, you may consider to use jetson_multiemdia_api, It is low-level APIs and eliminates latency in gstreamer frameworks. Please check document:
https://docs.nvidia.com/jetson/archives/l4t-archived/l4t-3242/index.html
And samples in

/use/src/jetson_multimedia_api