<div dir="auto">I might be wrong, that the bitrate unit would be kB, not Bits. <div dir="auto">And you could also try to add "is-live=true" to videotestsrc and add a queue before the encoder.</div><div dir="auto"><br></div><div dir="auto">Good luck.</div><div dir="auto"><br></div><div dir="auto">Yu</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 5 Aug 2021, 10:23 Nick Robillard via gstreamer-devel, <<a href="mailto:gstreamer-devel@lists.freedesktop.org">gstreamer-devel@lists.freedesktop.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When using the OpenMax encoder omxh264enc, I have found that setting control-rate=constant and specifying a value for target-bitrate causes GStreamer to hang indefinitely. It does not encode any output and does not show any error message (with debug mode disabled). It is very possible that I am not using the correct configuration. My goal is to produce a constant bitrate (or something close to it) stream at a specified bitrate that is suitable for live streaming to Twitch, Facebook, Youtube, etc. Is there a better or more correct way to achieve this?<br>
<br>
I have come up with a minimal example that has no external dependencies.<br>
<br>
This command works as expected:<br>
$ gst-launch-1.0 videotestsrc ! omxh264enc ! avimux ! filesink location=output.avi<br>
<br>
This command results in the described issue. I am attempting to achieve constant 4500Kbps bitrate:<br>
$ gst-launch-1.0 videotestsrc ! omxh264enc target-bitrate=4500000 control-rate=constant ! avimux ! filesink location=output.avi<br>
<br>
It should be noted that combining control-rate=variable with target-bitrate=<value> does not have this issue and appears to work as expected.<br>
<br>
My GStreamer version:<br>
<br>
$ gst-launch-1.0 --version<br>
gst-launch-1.0 version 1.18.4<br>
GStreamer 1.18.4<br>
<a href="http://packages.qa.debian.org/gstreamer1.0" rel="noreferrer noreferrer" target="_blank">http://packages.qa.debian.org/gstreamer1.0</a><br>
<br>
For the failure case, I have set different levels of debug and I’m not spotting anything obvious. Of course the debug output is massive at higher debug levels so I will link to some pastebins.<br>
<br>
Debug level 4. This log is full and complete. (I exited via control+c after a few minutes of seeing no more output.)<br>
<a href="https://pastebin.com/raw/C1nQrnpB" rel="noreferrer noreferrer" target="_blank">https://pastebin.com/raw/C1nQrnpB</a><br>
<br>
Debug level 5. This is a truncated log that includes the first 10th of a second of output due to length. It seems very repetitive.<br>
<a href="https://pastebin.com/raw/zqBMduhC" rel="noreferrer noreferrer" target="_blank">https://pastebin.com/raw/zqBMduhC</a><br>
<br>
</blockquote></div>