However, when replicating this using the C API, the output MP4 file is always only 36 bytes. When I looked closer and added in a tee to see whether the stream was running after launching, it turned out that the stream was freezing after the first frame. Running with the GStreamer debug warnings on, it gives the following:
Note that I tried both the nvv4l2h265enc and nvv4l2h264enc separately, and both froze. My guess is that there is some problem when negotiating between the h265parse element and qtmux.
One other thing to note is that when I swapped the qtmux element with avimux, and set the filesink to save an .avi file, this works using the C API. Thus, it appears to be a problem with only the qtmux element, but I am not sure how to further debug.
Since I am using nvarguscamerasrc and not appsrc, I need to use the format caps NV12, not I420. However, when using the above with only that difference, the a.mp4 file is still only 36 bytes. Is there any fix to this problem?
Thanks, I have a minimal example working with the the H.264 encoding and avimux. However, the qtmux still fails to produce any readable video. I now see a larger file size (a few MB), but there is no playable stream. I am using JetPack 4.2 on a TX2 if that makes any difference.
Thank you for your help. That was the issue. I had been modifying the nvgstcamera_capture sample to simultaneously log and insert data into VisionWorks, but since the sample is not intended for saving the data, I needed to add in the EOS signal. Thanks again.