07-25-2020 10:36 AM
Hello,
I'm using VCU TRD 2018.3 on ZCU106. I find that the clockoverlay plugin does not work with the OMX H264, H265 encoders.
The pipeline I'm using is -
gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, width=1920, height=1080, framerate=60/1, format=NV12 ! videoconvert ! videorate max-rate=25 ! clockoverlay time-format="%D%n%H:%M:%S" auto-resize=FALSE font-desc="Roman 14" deltax=100 deltay=100 halignment=1 silent=FALSE ! omxh265enc gop-length=10 gop-mode=basic low-bandwidth=FALSE target-bitrate=16384 b-frames=0 num-slices=1 control-rate=constant qp-mode=uniform prefetch-buffer=TRUE latency-mode=low-latency ! video/x-h265 ! h265parse ! fakesink
The last element above is fakesink for testing purposes. Same problem exists with matroskamux ! filesink too.
The error message is -
input buffer now has wrong alignment/stride, can't use dynamic allocation any more
The error message is a bit cryptic (atleast to me) because I haven't come across any alignment/stride setting for the encoder. The GST_DEBUG=5 log file is attached. Need help from a gst/omx expert to solve this. I'm pretty sure that the problem is the encoder configuration because the same pipeline on x86_64 works with x264enc/x265enc.
07-25-2020 11:52 PM
Hi @watari ,
Thanks for your reply.
1. A gst-inspect on omxh265enc only gives au as the alignment supported; there's no nal. And I know that AVC only supports au so, the same is true for omxh264enc.
2. I removed all the settings I had on omxh265enc so that it uses default settings (latency-mode=normal). The problem with clockoverlay persists.
I figured out that removing the videorate element fixes the issue. The working pipeline with clockoverlay is -
gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, width=1920, height=1080, framerate=60/1, format=NV12 ! queue ! clockoverlay time-format="%D%n%H:%M:%S" font-desc="Roman 14" deltax=100 deltay=100 ! omxh265enc ! video/x-h265 ! h265parse ! matroskamux ! filesink location=/media/usb/test.mkv
So, my situation right now is -
1. omx encoder works with videorate.
--------- OR ---------
2. omx encoder works with clockoverlay.
But not both! Weird.
Anyway, I was also able to get the required framerate by modifying the framerate caps. The only downside of this is that while video rate could have been changed during runtime, the caps can't.
07-25-2020 03:47 PM
Hi @rajatrao
You should add alignment=nal as caps. when you are using low latency mode.
Best regards,
07-25-2020 11:52 PM
Hi @watari ,
Thanks for your reply.
1. A gst-inspect on omxh265enc only gives au as the alignment supported; there's no nal. And I know that AVC only supports au so, the same is true for omxh264enc.
2. I removed all the settings I had on omxh265enc so that it uses default settings (latency-mode=normal). The problem with clockoverlay persists.
I figured out that removing the videorate element fixes the issue. The working pipeline with clockoverlay is -
gst-launch-1.0 v4l2src device=/dev/video0 io-mode=4 ! video/x-raw, width=1920, height=1080, framerate=60/1, format=NV12 ! queue ! clockoverlay time-format="%D%n%H:%M:%S" font-desc="Roman 14" deltax=100 deltay=100 ! omxh265enc ! video/x-h265 ! h265parse ! matroskamux ! filesink location=/media/usb/test.mkv
So, my situation right now is -
1. omx encoder works with videorate.
--------- OR ---------
2. omx encoder works with clockoverlay.
But not both! Weird.
Anyway, I was also able to get the required framerate by modifying the framerate caps. The only downside of this is that while video rate could have been changed during runtime, the caps can't.