[Bug 794799] New: pi: OMX encoder not reaching Executing when setting target-bitrate
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Thu Mar 29 10:03:19 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=794799
Bug ID: 794799
Summary: pi: OMX encoder not reaching Executing when setting
target-bitrate
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-omx
Assignee: gstreamer-bugs at lists.freedesktop.org
Reporter: gdesmott at gnome.org
QA Contact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Trying this pipeline with gst master:
gst-launch-1.0 videotestsrc ! omxh264enc target-bitrate=500000 control-rate=2 !
video/x-h264, profile="high" ! fakesink
The pipeline hangs waiting for the OMX component to reach the Executing state.
0:00:00.136477641 929 0x10cb860 INFO omx
gstomx.c:902:gst_omx_component_set_state:<omxh264enc-omxh264enc0> Setting
video_encode state from Idle to Executing
0:00:00.137169622 929 0x10cb860 DEBUG omx
gstomx.c:960:gst_omx_component_get_state:<omxh264enc-omxh264enc0> Getting state
of video_encode
0:00:00.137202904 929 0x10cb860 DEBUG omx
gstomx.c:460:gst_omx_component_wait_message:<omxh264enc-omxh264enc0>
video_encode waiting for signal
Thread 8 (Thread 0x733a1470 (LWP 936)):
#0 syscall () at ../sysdeps/unix/sysv/linux/arm/syscall.S:37
#1 0x76dae754 in g_cond_wait () from /lib/arm-linux-gnueabihf/libglib-2.0.so.0
#2 0x766d8fb8 in gst_omx_component_wait_message (comp=comp at entry=0x10226a0,
timeout=<optimized out>) at ../subprojects/gst-omx/omx/gstomx.c:469
#3 0x766ddd2c in gst_omx_component_get_state (comp=0x10226a0,
timeout=<optimized out>) at ../subprojects/gst-omx/omx/gstomx.c:981
#4 0x766f06b8 in gst_omx_video_enc_enable (input=<optimized out>,
self=0x10dc268) at ../subprojects/gst-omx/omx/gstomxvideoenc.c:2050
#5 gst_omx_video_enc_handle_frame (encoder=<optimized out>, frame=0x10f3de8)
at ../subprojects/gst-omx/omx/gstomxvideoenc.c:2584
#6 0x767c5384 in gst_video_encoder_chain (pad=<optimized out>,
parent=<optimized out>, buf=<optimized out>) at
../subprojects/gst-plugins-base/gst-libs/gst/video/gstvideoencoder.c:1548
#7 0x76eb515c in gst_pad_chain_data_unchecked (data=0x10f2e48, type=17603680,
pad=0x10d01d8) at ../subprojects/gstreamer/gst/gstpad.c:4279
#8 gst_pad_push_data (pad=pad at entry=0x10d0078, type=17603680, type at entry=4112,
data=data at entry=0x10f2e48) at ../subprojects/gstreamer/gst/gstpad.c:4535
#9 0x76ebf320 in gst_pad_push (pad=pad at entry=0x10d0078, buffer=0x10f2e48) at
../subprojects/gstreamer/gst/gstpad.c:4654
#10 0x76765534 in gst_base_src_loop (pad=0x10d0078) at
../subprojects/gstreamer/libs/gst/base/gstbasesrc.c:2957
#11 0x76ef3ee0 in gst_task_func (task=0x10f3828) at
../subprojects/gstreamer/gst/gsttask.c:332
Backtrace stopped: Cannot access memory at address 0x106ef0
This used to work at some point as these encoder settings were used to test bug
#698049
I tried reverting the omxvideoenc code to
5ba55b6c9aad49858304a38e0ab475c1ecafd646 (the commit fixing bug #698049) but
hit the same problem. So this may be a change/bug in the OMX implementation.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list