omxh264enc / v4l2jpegdec : stream hangs at low resolution, low bitrates and high motion
- Module: omxh264enc (gst-omx) and v4l2jpegdec (gst-plugins-good)
- Gstreamer version: 1.18.2
- OS: Linux raspberrypi 5.4.79-v7l+ #1373 SMP Mon Nov 23 13:27:40 GMT 2020 armv7l GNU/Linux
- Platform: Raspberry Pi 4b
Steps to reproduce:
Use the following video file as source: crash.mkv This video has a high level of random motion (fingers being moved closed to the camera) and was generated with:
gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg, width=640, height=480, framerate=30/1 ! matroskamux ! filesink location=crash.mkv
Gstreamer hangs after 3.7 seconds when trying the following:
gst-launch-1.0 filesrc location=crash.mkv ! matroskademux ! v4l2jpegdec ! omxh264enc target-bitrate=100000 control-rate=variable ! h264parse ! matroskamux ! filesink location=out.mkv
There is no special debug output (even with -v). Screenshot:
The process is still running and updating the terminal, but the timer shown is stuck at 3.7 seconds. When streaming a video the client sees a frozen image. When saving to a file nothing is written after that moment. CTRL-C stops the process and shows that the clock was still ticking in gstreamer's heart (0:02:10 in the output below):
pi@raspberrypi:~/$ gst-launch-1.0 filesrc location=crash.mkv ! matroskademux ! v4l2jpegdec ! omxh264enc target-bitrate=100000 control-rate=variable ! h264parse ! matroskamux ! filesink location=out.mkv Setting pipeline to PAUSED ... Pipeline is PREROLLING ... Pipeline is PREROLLED ... Setting pipeline to PLAYING ... New clock: GstSystemClock ^Chandling interrupt. (23.4 %) Interrupt: Stopping pipeline ... Execution ended after 0:02:10.355505474 Setting pipeline to NULL ... Freeing pipeline ...
If the bitrate is increased from 100000 to 200000 the process sometimes freezes around the 5.4s mark but is able to reach the end of the video most of the time. If the bitrate is lowered to 50000 the process always freezes sooner at 2.8s. In general, the freeze probability is higher when using:
- low bitrates
- low resolution
- high motion
This issue does not happen when jpegdec is used instead of v4l2jpegdec, but of course the former is slower and I'd like to use the newer v4l2 version.
It's not clear whether the problem is in v4l2jpegdec or the omxh264enc module.